►
From YouTube: 2022-02-03 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).
B
A
A
Oh,
we
can
get
started
with
team
splunk
make
your
ask:
hey.
D
I
could
probably
talk
about
this
one
since
I
wrote
this
in
the
doc
yeah,
so
we
were
curious.
If-
and
maybe
I
shouldn't
be
talking,
because
I'm
not
a
maintainer
but
whatever,
if
it
would
be
amenable
agreeable
to
use
some
triage
labels,
we
already
have
this
regression
label
that
exists.
We're
also
considering
the
use
of
a
new
label
called
patch
release.
So
this
would
be
like
anything
that
falls
under
the
criteria.
D
We
have
like
three
or
four
criteria
listed
for
types
of
or
classes
of
problem,
that
weren't
a
patch
release
and
so
being
able
to
assign
labels
or
commonly
assign
those
labels.
When
applicable,
I'm
saying
words
and
I'm
not
awake
yet,
I'm
sorry,
it's
okay!
I.
A
I
got
it
okay
yeah,
so
we
you're
right.
We
do
have
the
regression
label
we
may
not
be
using
it
consistently.
Is
that
the
con
is
that
the.
D
Ask
I
think
so
yeah,
but
also
being
able
to
like
explicitly
detect
when
something
is
patch
release
worthy.
D
Cool
yeah,
I
think
the
goal
is
just
to
be
able
to
surface
that
stuff
kind
of
look
more
broadly
like
for
people
that
want
to
to
be
a
little
more
aware
of
when
a
problem
is
critical
or
warranted
patch
release.
B
A
Yeah
the
we
could
also
use
milestone,
maybe
it's
a
little
less
visible.
A
It
could,
but
I
I'm
not.
I
think
I,
like
the
label
you're
right.
We
don't
tend
to
use
the
only
time
I've
I've
used
been
using
milestones
a
little
bit
for
like
when
we
have
say
111
coming
up,
and
I
know
we
want.
You
know
these
three
or
four
things
to
try
to
get
in
before
we
hit
the
button
just
so
I
don't
hit
the
button
too
soon.
A
Yep
awesome:
I
can
create.
D
I
just
I
figured
we
should
talk
about
it
instead
of
just
doing
it.
Oh.
E
C
E
A
Unless
it
wasn't,
unless
it's
been
there
forever.
C
I
guess
the
whole
point
is
to
like.
Currently
we
have
pretty
much
relied
on
making
the
batch
releases
and
figuring
out
which
issues
are
critical.
The
idea
is
to
make
it
like,
maybe
more
visible,
and
so
that
others
could
also
attack
the
issues,
that's
potentially
requiring
a
batch
release
so
that
we
wouldn't
miss
one.
E
There's
also
an
issue
like
a
very
general
issue
that
you
created
trust
about
triaging
in
our
backlog,
but
I
figured
that
we
probably
better
discuss
it
on
tuesday
and
it
doesn't
like
invalidate
the
concept
of
the
batteries
label.
E
If
you
try,
if
you
search
for
triage
with
triading,
oh
hold
on
a
second
I'll,
find
it.
A
We
talked
about
the
or
maybe
it
was
last.
We
talked
about
that
backlog
label
for
closing
things
out.
E
A
Cool,
so
I
have
any
last
thoughts
on
I
mean
I
think
it
makes
sense
to
me
to
replay
just
have
patch
release
as
a
replacement
for
and
we
can
delete
the
regression.
D
D
D
A
D
Is
well
it's
us,
it's
not
just
me
yeah
collectively.
We
wanted
to
ask
whether
we
could
be
consistent
in
providing
announcements
for
patch
releases
so
like
when
there
is
a
security
fix
or
something
that
warrants
a
patch
release,
putting
an
announcement
in
discussions.
A
D
A
That's
about
all
yeah,
I
totally
we
can
add
for
patches.
What
do
you
any
thoughts
on
whether
we
should
be
posting
discussions
for
all
releases?
A
I
mean
github
makes
it
easy.
It's
it
doesn't.
When
we
do
the
release,
there's
a
button
that
says
create
it,
create
a
discussion
so.
D
B
E
F
A
Gray,
okay,
okay,
yeah
yeah,
so
that's
more
support
to
doing
it
for
all
releases
to
be
consistent
with
the
core
repo.
A
All
right
I'd
put
this
on
here
is:
oh
okay.
We
can
chef
discuss
with
jack
this
evening.
Oh
john
also
made
some
comments.
F
A
Okay,
sorry
mateish.
E
F
Yeah
yeah,
but
those
two
things
are
kind
of
put
together
in
this
one.
Pr,
at
the
moment,
yeah
I
mean
we
could.
I
would
be
what
possibly
more
amenable
to
the
sdk
implementation
of
the
interface.
That's
returned
to
support
the
removal,
so
it
would
not
be
an
api
surface
change.
Then
you
would
be
required
to
cast
it
into
your
sdk
or
whatever
to
to
do
that.
E
F
A
F
F
Yeah
the
yeah
jack.
The
idea
here
was
that
we
could,
I
could
potentially
be
amenable
to
releasing
this
if
the
interface
on
the
api
doesn't
have
the
remove
or
whatever
that
I
don't
know
what
the
method
you
added
was,
but
if
the
sdk
implementation
had
it
so
that
the
agent
could
muck
about
with
it
or
people
could
reflection
to
find
it.
G
Yeah,
that's
that's
something
I
definitely
thought
about,
and
I
had
you
know
like
it's
definitely
possible
to
do,
and
I
I
considered
it
locally.
I
figured
we
would
have
to
do
something
like
that
in
order
to
merge
this,
if
we
actually
do
want
to
merge
this.
F
I
think
there
are
still
some,
I
think,
honorary
had
a
really
good
question.
I
think
it
was
having
to
do
with
like
the
prometheus
prometheus
support,
whether
whether
the
metric
would
still
be
being
reported
even
after
you
remove
the
callback-
and
I
think
I
don't
really
know
prometheus,
but
I
know
there
are
some
issues
if
metrics
start
disappearing
and
reappearing
that
there's
could
be
some
confusion.
F
G
Yeah
I
tried
to
address
that
so
with
async
instruments.
We
are
essentially
delegating
the
management
of
the
metric
stream
to
the
callbacks
in
and
what
that?
What?
That
means
is
that
if
a
callback
stops
reporting
a
particular
set
of
attributes,
then
we
stop
exporting
it,
and
this
pr
doesn't
change
that.
It
doesn't
address
that
anyway,.
F
G
Yeah,
you
know
if
we
did
decide
to
keep
this
at
the
sdk
and
not
add
the
method
in
the
the
api
there's
kind
of
precedent
for
that
right.
So
the
the
bind
api
that
we
have
is
still
available
in
the
sdk,
but
we
don't
expose
it
via
the
api.
G
So
that's
one
thought
that
crossed
my
mind
and
then
another
thought
that
I
had
was
well
in
and
I
don't
know.
I
think
this
is
actually
an
argument
against
including
this,
but
so
the
spec,
not
only
does
it
say,
not
provide
a
provision
for
having
this
remove
or
close
method
at
the
api
level.
It
also
explicitly
disallows
having
multiple
callbacks
right
now.
So
I
think
multiple
things
need
to
be
changed
in
the
at
the
spec
level.
For
this
to
you
know,
be
fully
approved.
E
G
So
I
think
it's
it's
kind
of
an
interesting
situation
right
now,
because
this
back
the
spec
says
that
the
api
should
throw
an
error.
If
you
ever
ask
the
same
meter
for
the
same
instrument
twice,
and
so
you
know
whether
that
be
synchronous
or
asynchronous.
That's
supposed
to
be
an
error.
Today,
our
implementation
allows
you
to
obtain
the
same
instrument
multiple
times
as
long
as
it's
synchronous
and
for
asynchronous
instruments.
We
just
we
take
the
first
callback
that
you
register
and
we
ignore
subsequent
ones.
G
So
our
sdk
is
actually
not
in
alignment
with
the
spec
today
for
for
synchronous
instruments
and
for
asynchronous
instruments,
it
is
aligned
with
this
spec.
So
this
would
this
change
makes
it
makes
it
so
that
we
are
consistently
not
in
alignment
with
the
spec
for
both
async
and
synchronous
instruments.
E
Yeah,
that's
true:
okay,
yeah.
I
think
I
remember
reading
something
about
like
mentioning
callbacks
in
plural,
a
lot
in
singular
but
yeah.
It's
true
that
it
does
disallow
multiple
registrations.
A
It'll
be
interesting,
we'll
see
if
josh
is
able
to
make
it
this
evening
would
love
to
get
his
thoughts.
Also
on
from
perspective
of
kind
of
going
forward.
With
this
or
waiting,
I
mean,
certainly
we
can
wait.
You
know.
G
A
G
I
I
I
will
do
this
today,
so
I
added
the
I
added
this
for
metrics.
So
there's
now
on
a
configurer
for
like
an
sdk
meter
provider
configurer
and
a
configurable
metric
exporter
provider,
and
so
I
I
think
you
know
I've
been
working
to
add
symmetry
between
traces,
metrics
and
logs
logs
was
just
last,
but
the
metrics
pr
got
merged,
and
so
it
should
be
pretty
straightforward
to
add
the
logs
one.
A
F
A
Quite
a
I
was,
I
didn't,
make
a
list,
but
I
think
there
were
some
pretty
important
things
in
the
java
agent.
A
A
G
G
It's
the
the
process,
command
line
attribute,
and
it's
often
really
really
long
like
you
know
a
thousand
characters
plus
and
it
can
contain,
depending
on
how
you're
doing
things
secret
information.
So
the
way
that
you
exclude
the
process
command
line
resource
attribute
right
now.
It's
it's
not
great
because
you
have
to
you
have
to
disable
the
entire
process
resource
provider,
which
has
other
useful
attributes
in
it,
and
I
was
wondering
if
you
know
if,
if,
if
the
group
had
any
thoughts
on
excluding
individual
resource
attributes
via
some
mechanism,.
F
F
I
actually
might
prefer
to
exclude
the
command
line
by
default
and
actually
have
a
separate
resource
provider
to
add
the
command
line,
maybe,
and
so,
and
that
would
have
to
be,
and
so
that
would
be
really
easy
to
exclude
just
that,
one
that
one
provider
it's
a
little.
So
I
mean
it's
a
little
extra
code,
but
it
seems
like
that,
breaking
that
down
into
two
pieces
might
be
a
viable
way
without
having
to
invent
some
new
configuration
language
for
specific
attributes
to
be
alive.
G
F
D
F
A
F
Think
first
step
would
probably
be
to
split
it
so
that
it
could
be
individually
disabled.
G
Yeah
I
can.
I
can
do
that.
One
thought
that
I
have
there
or
just
like
a
consideration,
is
that
the
the
package
that
it's
in
is
stable
or
the
artifact
that
it's
in
is
stable,
and
so
this
is
kind
of
a
behavioral
change
to
change
like
kind
of
what's
emitted
attached
to
your
data
as
a
result
of
this,
not
an
api
change
of
that
module.
G
F
Yeah,
which
seems
that
doesn't
seem
like
a
problem
to
me.
It
seems
fine,
but
let's
we
can
chat
about
it
with
honorable
tonight,
but
it
seemed
that
I
don't
think
that's
necessarily
a
problem
like,
as
jason
said,
this
is
super
useful
in
some
cases,
so
having
it
around
seems
like
a
good
idea.
A
F
G
Trust
they
would
have
to
switch
which
resource
provider
they
disable
and
so
basically
change
the
class.
The
fully
qualified
class
name
that
they're
providing
via
you
know,
system,
property
or
environment
variable.
D
Yeah-
and
it
is
wacky
that
that
is
ingested
on
every
span,
it's
almost
like,
because
it
doesn't
change
for
the
life
cycle
of
your
process
right
all
resource
attributes
are
like
that.
I
know
I'm
just
I'm
wondering
like
what
could
be
done
about
it
like
it.
It
almost
wants
to
just
be
a
log,
a
log
event,
a
log
message
that
can
then
be
somehow
correlated
through
the
rest
of
the
resource.
G
I
want
to
hate
having
an
experimental
environment
variable
or
system
property
to
have
a
disallowed
list
of
resource
attributes,
so
you
know,
resolve
all
your
resource
providers
and
see
all
the
attributes
that
are
attached
to
them
and
after
that
process
is
done,
go
through
this
disallow
list
and
prune
ones
that
occur
on
that,
and
you
know
it's
not
it's
not
supported
at
the
spec
level,
but
I
could
see
it
being
supported
one
day.
A
E
I
have
a
topic
somewhat,
but
not
well-defined
one
though
so
we
have
the
spring
boot,
auto,
configure
module
right
and
it's
being
used,
apparently
because
from
time
to
time
some
people
bump
issues
that
are
reported
on
it
or
issues
about
it,
and
it's
completely
I
mean
we
almost
completely
do
not
maintain
it.
It
doesn't
get
the
new
spring,
instrumentations
or
micrometer
for
that
matter.
It
also
didn't
get
that
and
it's
lacking
some
like
very
basic
feature
like
setting
the
service
name,
and
do
we
have
any
plans
for
that?
A
Yeah,
so
I
mean
we've
early
on.
We
were
thinking
that
the
the
the
spring
cloud
sleuth
stuff
might
handle
that.
So
I
don't
know
what,
but
I
I
know
it's
still
it
could
be.
I
mean
people
love
their
spring
boot,
auto,
configure
stuff,
I
mean
really
love
it,
and
so
it's
nice
to.
I
think
it
would
be
nice
to
have
one
that
maps.
A
You
know
direct
open,
telemetry
concepts
for
people
who
don't
want
to
go
through
a
sleuth
hotel
bridge,
which
we
know
at
least
currently
has
a
lot
of
kind
of
rough
edges
and
even
in
the
long
run
is
going
to
be.
You
know,
kind
of
a
dual
experience
of
sleuth
and
hotel
versus.
If
I
could
see
some
people,
you
know
benefiting
from
a
simple
or
just
straight
hotel
experience.
H
Guys,
let
me
give
you
a
bit
of
feedback
on
this,
because
we
are
going
to
start
using
this
springboot.configure
on
the
company.
I
work
and
I
think
it's
actually
well
interesting
to
have
it,
at
least
from
our
perspective.
G
So
so
what
what
things
do
you
want
to?
Would
you
want
to?
You
know,
be
able
to
have
control
over
configuring,
because
I'm
looking
at
this
code
and
I'm
kind
of
unfamiliar
with
it,
but
you
know
the
gist
of
it.
That
I'm
getting
is
that
it
kind
of
recreates
our
auto
configure
module
it.
It
essentially
tries
to.
G
You
know,
provide
options
for
you
to
configure
the
the
building
block,
components,
the
exporters,
the
processors
and
compose
those
into
you
know
sdk
tracer
provider
and
meter
provider,
and
things
like
that
and
a
lot
of
that
functionality
is
provided
out
of
the
box
by
the
hotel,
auto
configuration
module.
H
G
I
would,
I
would
say
so:
the
auto
configuration
module
has
this
notion
of
an
auto
configure
customizer,
and
if
you
implement
this
interface
or
if
you
it
provides
you
a
hook
to
basically
extend
and
customize
all
the
components
of
of
the
open,
telemetry
sdk
and
we're
going
to
continue
to
add
more
hooks
as
as
more
components
become
available
and
need
customization.
We
were
talking
about
extending
it
with
customizers
for
for
logging
earlier
on.
G
This
call,
and
I'm
wondering
if
like
if
somehow
that
could
be
exposed
to
spring
boot,
auto
configuration
users
so
such
that
you
know
we
can
leverage
the
auto
configuration
auto,
configure
code
from
the
open,
telemetry
sdk
as
much
as
possible,
but
give
spring
boot
users
a
hook
into
it
via
this
customizer.
E
Be
great
if
spin
users
could
just
register
the
customized
providers
as
spring
beans
now
those
spi
right,
because.
H
Just
another
thing
this:
this
is
the
part
where
so
the
company
has
a
lot
of
microservices
and
one
part
is
implemented
with
springboot,
but
the
some
others
are
implemented
with
quarkus
and
we
are
actually
on
microprofile.
That's
carcases
in
implement
implements
part
of
the
microfile
specs.
We
on
microprofile
are
trying
to
create
a
kind
of
a
bridge.
H
Let's
say
a
bridge
spec
to
integrate
seamlessly
with
open
telemetry,
and
one
of
the
things
that
we
will
need
to
to
bootstrap
is
the
configuration
so
making
kind
of
a
bridge
between
micro
profile
config
and
these
configurations
here
and
it's
the
exact
same
use
case,
but
with
a
different
framework.
G
But
I
wonder
if
the
quark
is
in
microprofile,
allow
you
to
have
access
to
these
customizers
so
that
you
can
implement
it
and
have
a
similar
hook
for
customizing.
The
sdk
configuration
in
either
framework.
I
I
So
the
the
that
only
became
available
in
legislative
was
like
last
week,
I
believe
or
like
10
days
ago,
or
something
like
that
and
I
haven't
got
much
time
to
to
to
to
to
start
doing
the
work.
But
but
I
have
a
few
prototypes
and
some
of
the
pull
requests
that
I
opened
was
mostly
based
on
on
the
work
that
I
was
doing
to
move
everything.
That's
corpus
configuration
to
use
the
open,
telemetry
configuration
and
I
believe,
most
of
the
things
that
we
were
requiring
are
already
there
now.
G
That
that
sounds
great.
Just
quick,
quick
follow-up
question
is
the
plan
for
quarkx
to
expose
the
ability
to
to
users
to
customize
the
configuration
via
the
you
know,
the
customizer
interface
unlikely
at.
I
This
point:
maybe
we
will
expose
that
in
the
future-
sorry
so
yeah.
Maybe
we
will
expose
that
in
the
future,
but
right
now
we
just
want
users
to
be
able
to
use
open,
telemetry
configuration
properties
and
be
able
to
configure
the
open
203
environment
with
what's
out
there
right,
okay,
but
maybe
in
the
future,
we'll
allow.
I
I
mean,
step
by
step
right,
let's,
let's
just
we,
we
want
first
to
be
able
to
for
users
to
be
able
to
to
use
the
opportunity,
configuration
properties
and
then
we'll
figure
out.
The
rest
makes
sense.
A
A
And
ideally,
if
we
could
kind
of
show
a
nice
example
of
how
to
do
it
in
spring
boot,
that
could
also
help-
or
in
this
case,
taking
the
lead
and
helping
kind
of
drive
that
path
forward,
and
we
can
probably
benefit
from
those
enhancements
like
the
shutdown
hook.
That's
a
really
important
one.
A
And
bruno
we're,
definitely
I
mean
any
if
you
run
across
anything,
you
know
and
feel
like
sending
prs
were
while
we
haven't
been
tackling
this.
Currently,
we
would
love
prs
and
and
help
on
it.
A
Cool
any
new
topics
pop
into
anybody's
heads.
A
All
right,
let's
end
and
see
some
of
you
on
monday
and
metrics
and
next
week
back
see
you
later.