►
From YouTube: 2021-07-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
A
B
E
D
Yeah,
that
was
definitely
user
error,
just
clicked
some
bunch
of
buttons.
I
got
impatient
with
zoom
joining,
and
so
I
clicked
manual
join
button
but
then
like
and
then
I
had
to
reconnect
anyway.
Yes,
user
failure.
A
D
About
yeah,
let
me
bump
I'm
gonna
bump
your
topic.
That's.
C
B
I
will
just
jump
in
on
that
then,
while
you
pull
that
up,
so
the
action
to
publish
the
base
image
got
merged,
but
I
don't
think
it's
run
yet
and
then
I
have
two
pr's
waiting
for
that
image
to
be
there.
D
B
D
Okay,
can
we
run
it
manually.
B
B
Cool-
and
we
don't
know
if
this
will
work
right,
I
don't
know
if
you
were
following
the
comments
on
it,
but
the
idea
was
that
I
guess
all
of
the
other
stuff
that
we
published
to
the
container
repo.
We
just
put
a
tag
on
the
same
test.
Containers
image
right
and
this
has
a
different
name.
So
if
it,
if
it
creates
it,
then
we'll
be
lucky.
B
D
B
Pop
okay
yeah,
it
might
require
an
org
admin.
So
if
this
fails,
I
can
go
back
and
change
it
to
to
be
the
similar
approach
to
the
way
that
other
images
that
we
publish
or
published.
But
it
seems
like
a
mistake
to
me-
and
I
put
this
comment
in
the
in
the
thing-
it
seems
like
a
mistake-
to
publish
as
test
containers
when
it's
clearly
not.
I
mean
I
guess
it
is
a
container
in
the
for
testing,
but
what
we
publish
is
called
test
containers,
even
though
this
is
pet
clinic.
So.
D
Yeah,
if
it
doesn't
work,
let's
just
request
a
new,
a
new
container.
D
Okay,
if
you
post
an
issue
to
the
community
repo
okay
asking
for
that,
I
think
that's
where
we
had
asked
for
that
container.
D
Yeah,
it
shouldn't
be
a
big
deal
to
request
a
new
one
and
okay.
D
Own
that,
if
this
fails,
I
can
I
can
do
that
cool
just
I
either
tag
me
or
post
in
slack
just
so
I
can
thumbs
up
it
because
they'll
want
a
maintainer
like
approval.
B
C
B
B
Yeah,
the
other.
I
have
a
separate
task
to
actually
set
this
up
to
be
a
scheduled
run.
I
figure
once
once
it's
a
little
more
stable.
I
don't
want
to
schedule
it
to
run
nightly
if
it's
just
not
working
or
if
it's
not
fully
formed.
B
B
So
I'm
looking
for
feedback
on
this
config
stuff
too,
because
it
feels
like
it
might
be
a
like.
I
think
it's
pretty
flexible,
but
it
might
be
a
little
bit
over
engineered,
and
I
know
that
watson
had
some
feedback
about
the
agent
names
being,
maybe
overly
simple
and
I'm
happy
to
talk
through
details.
If
that's
good
for
this
call,
otherwise
we
can
just
take
it
to
the
to
the
pr.
B
So
so
there
is
a
there
is
a
set
of
configurations
in
which
you
can
define
all
of
the
agents
that
you
want
to
run
so
either
none
in
snapshot,
none
and
release,
release
and
snapshot
like
you
can
combine
any
permutation
of
those
agents.
What
I've,
what
I'm
calling
agents
and
then
you
can
define
the
number
of
concurrent
users
and
the
maximum
number
of
iterations
through
the
test
file
to
make,
and
it
can
be
different
between
those.
So
if
you
wanted
to
do
like
a
heavy
configuration
versus
a
light
configuration
that
could
be
defined.
D
D
B
B
B
And
this
is
all
up
to
change
right,
like
I
mean
we
can
put
whatever
we
want
in
there
and
the
I'm
using
defaults
for
the
concurrent
users
and
the
amount
of
load.
B
D
Okay-
and
these
I
see-
and
these
are
the
the
knobs
exactly
and
do
you
is
that
in
code,
where
you
set
up
the
test
config
or
does
that
parse
some
kind
of
config
file.
B
No,
it's
all
in
code
right
now
and
that's
because
we're
using
test
containers
like
originally
inspect.
I
had
planned
on
defining
like
a
config
file
format,
but
since
we
have
test
containers,
let's
just
do
the
simple
thing
and
keep
it
in
code.
B
Right
nikita
also
had
some
feedback
about
the
approach
I
took
for
resolving
snapshots,
I'm
hitting
the
I'm
hitting
the
sona
type
xml
metadata,
endpoints
and
parsing
the
xml
to
like
it's
a
two-stage
process
to
find
the
actual
latest
snapshot
jar
and
he's
like
don't
use
that
use
eclipse
ether
and
I'm
like
that
project
is
dead
and
he's
like.
But
then
he
sent
me
a
link
to
like
some
some
other
project.
That'll.
Do
it
so
there's
some
crafty
code
in
here
that
does
the
painful
lookup
that
I
think
we
can
improve.
D
Yeah
so
okay,
yeah
yeah.
I
I
like
that
john's
proposal
also.
C
C
C
C
B
B
E
A
D
A
Yet
yeah,
so
as
I
comment
there,
let
you
just
leave
it
there.
It
is
back
so
I've
been
working
with
kind
of
hackathon
week
here
at
splunk,
so
I've
been
hacking
on
stuff,
so
I
have
written
a
gradle
plugin
that
will
instrument.
Gradle
builds
with
open
telemetry
and
it's
pretty
cool
but-
and
I
would
love
love
it.
A
If
there
were
a
way
we
place,
we
could
send
spans
and
like
plug
this
into
our
ci
and
actually
be
able
to
see
like
tracing
of
our
gradle
builds,
because
I
think
it's
not
only
you
know
it
would
be
useful.
I
think,
or
could
be
useful,
especially
when
things
are
slow
to
see
what
tasks
are
slow
in
a
more
visual
form.
A
Github
doesn't
it
has
a
docker
registry,
but
it
doesn't
have
like
a
apm
back
end.
Unfortunately,
I
mean,
unless
microsoft,
unless
you
can,
you
know
plug
in
through
your
all
your
great
new
github
connections
anyway,
I
think
this
is
something
that
could
be
pretty
cool
and
useful.
I
just
have
no
idea
where
to
send
the
data
I
can
demo
sending
it
to
our
splunk
apm.
A
A
Hopefully,
let's
do
the
right
one.
So
here
can
people
see
some
chromary
anyway,
so
here's
two
little
builds.
I
just
did
earlier
today
messing
around
so
I've
been
trying
it
out
with
multiple
projects,
just
to
make
sure
that
didn't
run
into
gotchas,
but
here's
an
example
of
our
splunk
android
rum,
build
one
that
I
introduced.
A
failure
on
purpose.
Just
to
show
that
you
know
you
can
see
build
failures.
A
So,
for
example,
here's
optimizing
release
resources
inside
the
sample
app
took
60
seconds.
I
don't
have
any
idea
why
but
and
then
you
go
down
here,
you
can
actually
see
you
know
here's
the
failure
you
can,
at
least
in
our
ui.
You
can.
You
know,
click
in
here
and
see
here's
the
stack
trace
that
happened
in
this
case.
I
just
made
a
test
fail,
so
it's
kind
of
cool
and
then,
if
we
look
at
this,
the
actual
open,
telemetry
java,
so
I
plug
this
into
our
own
build.
A
So
here
we
are
really
eating
our
own
dog
food
or
the
snake
is
eating
its
tail,
I'm
not
sure
which,
depending
on
how
you
want
to
visualize
it
and
here's,
you
know
the
1100
tasks
that
execute
as
a
part
of
the
open
telemetry
java
build.
I
am
a
little
scared
about
what
this
would
do
if
I
put
it
into
the
instrumentation
build,
but
one
thing
that
I
think
is
also
nice.
I
don't
think
we
have
a
fantastic
ui
for
this,
but
I'm
also
pulling
in
resources.
A
So
you
can
see
what
you
know
what
the
os
it
was
running
on.
You
know
the
host
name,
all
this
kind
of
stuff
so
pulling
in
the
automatic.
The
auto
resource
is
not
a
configuration
for
open,
telemetry
and
like
gradle.
What
are
you
doing?
What
command,
what
the
heck
is?
This
great
old
command
line
is
calling
in
the
java
process.
It's
wacky.
D
It's
a
bunch
of
working
around
java,
9
modules.
It
looks
like
yeah.
A
Probably
anyway,
so
yeah
that's
what
I've
been
hacking
on
is
actually
instrumenting.
Gradle
builds
with
open,
telemetry,
so
yeah.
I
think
this
would
be
super
rad
if
we
had
a
place
to
send
this
data
that
wasn't
just
sending
to
our
you
know:
splunk
internal
internal
app
and
that's
not
gonna,
wouldn't
work
for
anyone
to
do
anything
with
anyway.
A
So
I
don't
know
if
some
back-end
vendor
thinks
that
this
is
a
good
provide.
You
know
something
to
the
community.
That
would
be
great,
I'm
going
to
ask
internally
at
splunk
also,
but
I
given
the
way
that
our
business
is
structured,
I
think,
would
be
unlikely.
It's
not
really
a
free
tier
sort
of
thing.
It's
fun.
A
D
Instance
in
well
in
amazon,
since
that's
the
cncf,
has
that
we
have.
We
already
have
stuff
running
in
amazon.
We
could
set
up
a
vm,
run
jager
and
just
make
it.
You
know
public.
D
F
A
A
A
I
was
actually
surprised
at
how
much
you
get
access
to,
but
also
surprisingly,
how
much
you
don't
get
access
to.
For
example,
you
know
with
a
gradle
sub,
with
a
gradle
project
as
a
whole,
like
the
brute
project
you
get
call
backs
for
when
the
build
starts
and
ends,
but
you
don't
get
that
on
sub
modules.
A
So
there's
actually
no
way
to
know
when
a
particular
sub
module
is
done
building
unless
you
somehow
manage
to
gather
up
all
the
tasks
associated
with
that
module
and
then
track
them
all
and
figure
out
when
it's
when
it's
complete,
which
I
did
try
and
wasn't
able
to
get
it
to
work.
I
did
I
tried,
for
you,
know
an
hour,
so
it
wasn't
able
to
get
it
to
work
consistently.
A
A
D
Yeah
or
in
the
I'm
gonna
probably
get
more
visibility
in
the
community
repo.
D
Yeah
because
it
feels
like
something
that
could
be
a
nice
open,
telemetry-wide
resource
to
have
a
back-end
like
a
public
jaeger
instance
that
people
can
push
test
data
to
for
demo
and
for
dog
fooding.
Just.
C
A
B
A
Be
also
be
nice
if
there
were
a
prometheus
back
end
in
there
as
well,
so
you
could
get
metrics.
A
E
D
C
C
E
Yeah,
so
we
had
the
discussion
so
all
started
that,
like
two
days
ago,
we
had
the
latest
dependency
test,
failing
because
couchbase
released
a
new
version
and
they
have
changed
something
in
there.
So
api
has
changed.
The
interesting
part
is
that
couchbase
has
already
for
some
versions
native
integration
with
open
telemetry.
E
So
it's
like
a
plugin
for
college
base
that
you
can
have
open
telemetry
api
based
telemetry.
So
my
question
was:
do
you
actually?
But,
but
we
still
have
java
agent
integration
for
that
library
in
order
to
like
automatically
plug
in
that
plug-in,
so
opt-in
that
plugin,
which
is
distributed
as
a
separate
plugin?
So
my
question
was:
do
we
want
steel
to
have
that
burden
of
supporting
wider
community
libraries
and
frameworks
after
the
fact
that
they
have
already
open
telemetry
integration
built
in
either
like
built
in
in
the
library
directly
or
having
a
plug-in
opt-in?
E
D
So
I'm
bringing
up
this
list
because
to
me
like
most
of
these,
like
I
would,
if
it
was
one
of
these
libraries
that
say
kafka,
say
we're
talking
about
so
couch
base.
I
I
I
would
be
okay
with
not
providing
java
agent
instrumentation,
I
don't.
D
We
don't
even
pull
that
into
our
distro
yet,
but
for
the
you
know
for
our
tier
one,
most
popular
java
libraries
if
they
built
it
in
then
yes,
certainly,
we
would
not
need
java
agent
instrumentation
for
that,
because
if
we
would
auto
collect
that,
but
say
kafka
had
an
ex
extra
dependency
users
had
to
pull
in.
D
I
wouldn't
want
to
have
to
tell
customers
that
they
have
to
go
and
add
that,
just
because
there's
there's
two
types
of
right
right,
a
big
customer
they
target
is
ops
folks
who
just
have
an
app
and
they
want
observe.
They
need
visibility
into
the
app
they
need
distributed
tracing
to
see.
You
know
where
there's
bottlenecks
in
their
infrastructure,
and
so
they
don't
have
the
option,
often
of
modifying
the
app
or
it's
not
convenient.
E
D
E
E
E
Okay,
assuming
that
all
our
muzzle
infrastructure
will
take
care
of
that,
let's
assume
that,
but
the
second
problem
is,
if
we
just
take
that
once
we
provide
end
user
with,
like
suboptimal
experience
that
some
like
year
year,
old
integration,
so
how
that
means
that
we
have
to
actually
actively
monitor
the
third
party
integration
with
open
telemetry
in
order
to
upgrade
them
it's
it.
E
D
I
think
that
was
what
we
discussed
on
tuesday.
Did
I
write
yeah?
No.
Did
I
not
take
notes
on
that,
so
I
think
we
agreed
that
we
want
to
push.
We
want
to
work
with
those
groups
to
improve
their
telemetry.
D
E
E
D
I
think
jason
expressed
his
opinion
at
the
beginning,
which
is
talk
to
your
product
manager.
A
Yeah,
I
wonder
just
you
know-
I
missed
some
of
the
conversation,
but
I
wonder
if,
like
for
the
plug-in
the
plug-in
one,
which
is
you
know
difficult,
it's
the
hard
one
really
right
to
figure
out
how
to
do
if,
if
the
agent
supported
the
main
main
based
running
of
the
agent
which
we've
talked
about
like
be
able
to
plug
in
the
plug
in
the
agent
as
a
part
of
your
startup,
rather
than
putting
it
on
the
job
as
a
dash
java
agent
command
line.
A
If
we
ended
up
implementing
that
capability,
then
if
the
agent
jar
that
supported
that
had
dependencies,
they
could
just
pull
those
in
and
it
could
work
right.
That
would
just
be
kind
of
a
part
of
that
startup
or
part
of
the
dependency
chain,
but
that
would
require
us
figuring
out
how
to
do
that
kind
of
main
based
agent
startup,
so
the
dependency
would
get
pulled
in
automatically.
D
Yeah,
I
don't
think
it's
really.
I
don't
see
it
related
to
the
to
the
main
pulling
it
in
that
way,
because
we
already
do
have
a
way
of
injecting
it
into
the
class
loader
where
it's
needed.
A
Plugins
I
understand,
but
if
we
did,
if
we
didn't
want
to
bundle
them
into
the
agent,
this
seems
like
having
a
having
an
agent
jar
that
you
could
put
on
your
like
and
call
a
thing
at
the
first
line
of
your
main.
They
would
install
the
agent.
You
could
also
just
have
that
plug-in
as
a
dependency
for
that
particular
model.
So
it
would
get
slipped
in
automatically.
D
A
I
was
thinking
for
distribution
for
for
people
who
are
writing
this
who
doing
custom
distributions.
They
could
have
that
automatically
a
part
of
their
distribution
if
they
wanted
to
have
it,
which
I
guess
they
could
do
it.
I
don't
know
I'm
just
kind
of
brainstorming.
This
whole
thing,
because
I
really
want
that
main
method.
One.
I
want
to
push
for
that.
E
Got
it
well,
john,
you
can,
you
can
rest
assure
we
are
going
to
have
that
because
we
have
that
customer
that
wants
that
yeah.
A
D
A
E
E
I
mean
my
not
main
concern,
but
one
of
the
big
concerns
is
that
in
the
long
run,
if
and
when
open
telemetry
is
successful
and
a
lot
of
libraries
does
like
integrate
with
with
open
telemetry
natively,
I
in
hope
that
that
will
mean
less
support
burden
on
open,
telemetry
maintainers,
but
if
we
still
have
to
have
those
integrations
and
especially
bundling
in
those
plugins,
that
will
not
be
the
case.
Our
our
our
support
burden
will
diminish
much
less.
E
D
D
20
instrumentations,
so
the
long
tail
I
would
I
would
be
okay
with
not
doing
auto
instrumentation.
Once
a
library
has
a
plug-in.
D
Okay,
it
sounded
like
from
slack
that
honorable
might
have
a
different
opinion
of
providing
auto
instrumentation
even
for
contrib
stuff.
E
So
should
we
take
that
in
or
should
we
accept
it
or
not?
Probably
yes
into
country,
that's
not
our
maintainer's
burden.
Sure
you
want
to
support
that
go
on.
If
you
don't
support
that
we
we
drop
that
so
that
we
have
like
official
official
po
po
policy.
So
the
probably
indeed
my
question
is
only
about
integrations
with
within
main
reaper
and
that
by
the
way,
answers
like
a
vendor
pm
question
as
well.
E
So
if,
if
vendors
think
this
is
important,
so
they
can
either
have
that
in
the
vendor
distribution
or
contribute
that
into
concrete,
that's
it,
so
nobody
will
block
them
and
in
the
majority
of
cases
that
will
anyway
will
be
the
same
people
implementing
that
just
destination
a
little
bit
different,
so,
okay,
yeah
that
I
can
live
with
also.
I
still
think
that
bundling
in
some
old
version
is
a
bad
idea.
D
Yeah,
so
that
part
of
one
thing
we
had
discussed
on
the
contrib
stuff
was
moving
all
old
version
support
into
contrib.
E
But
that
is
very
interesting,
separate
question.
I
mean:
how
can
we,
how
can
how
do
we
draw
that
line?
Now,
it's
old
enough
to
move
from
mainly
but
to
to
to
contrib.
If,
if
per
chance,
we
have
the
same
integration
working
for
five
years
worth
of
version
upgrades
right
because,
because
that's
closer
and
there
is
stable
api,
nothing
changes.
D
Yeah-
and
that
is
a
big
consumer
customer
base
for
the
atm
vendors-
is
people
running
old
apps
that
just
they
can't
touch
the
code.
They
just
want
it
to
keep
running
and
keep.
A
D
Unless
josh,
maybe
worth
pinging
josh
to
see
if
he
wanted
to
chat
metrics
since
he
joined
sometimes.
C
D
I
added
this.
It
was
basically
something
nikita
brought
up
earlier
this
week.
So
did
nikita.
Did
you
happen
to
think
about
if
the
the
extension
mechanism,
if
we
need
the
java
agent
extension
api
to
for
like
say
somebody
wants
to
plug
in
you
know
just
a
sampler
or
a
span
processor?
D
D
So
part
of
what
this
discussion
was
is
the
java
agent
extension.
Api
is
probably
a
little
ways
out
still
from
being
stable,
because
it's
got
all
all
the
java
agent
instrumentation
stuff
in
there.
But
there
is
a
desire-
and
I
saw
I
saw
our
first
customer
who
was
kind
of
pushing
for
this.
Also
to
for
some
of
the
basic
configuration
things
in
open
plan
that
open
telemetry
sort
of
promises
from
the
sdk
perspective.
Samplers
span
processors-
I
don't
know-
maybe
propagators-
maybe
exporters.
D
If
we
can,
if
our
extension
mechanism
could
be
stable
or
if
for
adding
these
primarily
all
of
we
think
it's
mostly
just
reusing
the
auto
configure
artifact
from
the
sdk
repo,
in
which
case
john,
is
the
auto
configure
artifact
stable,
no
still
alpha,
because.
D
A
C
D
D
Long,
yes,
I
will
keep
pointing
you
instrumenter
at
our.
D
Yeah,
I
I
and
my
apologies.
I
have
not.
I've
been
pulled
away
the
last
week
or
so
so
I
have
been
making
zero
progress
on
this
or
anything
else.
Open,
telemetry
related.
E
And
I
haven't
even
I
haven't
even
reviewed
any
of
that
conversion
polar
cast.
So
no
blame
for
me.
D
It's
kind
of
good
if
we
all
coordinate
our
there's
except,
I
feel
bad
for
the
people
who
are
still
submitting
prs,
like
jason
and
they're,
not
getting
reviewed
very
quickly.
It's
fine.
D
All
right,
y'all,
well,
we've
got
two
minutes
left.
If
anybody
has
any
last
topics,
thoughts.