►
From YouTube: 2021-07-29 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
C
All
right,
yeah
sure,
okay,
so,
as
usual,
please
add
your
name
to
the
attendees
list.
C
We
have
a
couple
of
topics
today,
specifically
the
distro
discussion
that
we
were
having
last
week
and
the
also
some
topics
about
the
release
process
that
the
maintainers
felt
like
was
appropriate
to
bring
up
so
where
we
left
off
last
week
was
diego
had
a
at
a
pr
for
the
post
and
pre
entry
points.
It's
like
a
bit
of
an
add-on
or
a
new
design
to
a
new
way.
C
We
want
to
implement
how
you
want
to
use
this
drills,
and
I
think
we
wanted
everyone
to
look
at
that
pr
and
see.
If
there's
any,
you
know,
arguments
or
point
of
contentions
for
that.
C
A
A
Row
as
a
component
which
hooks
into
this
first
entry
point
and
that
other
component
provides
its
own
entry
point,
I
don't
think
this
is
in
this
pr.
No
because
this
this
car
only
includes
the
entry
points,
but
since
this
is
related
to
this
other
pr,
I'm
gonna
talk
about
that
real
quick
so
that
you
get
a
complete
picture.
I
have
this
other
pr
name
refactor.
These
throws.
A
A
Okay,
so
yeah,
so
what
this
vr
the
refactoring
of
distrust?
What
does
is
that
it
uses
the
pre-instrument
entry
point
to
call
this
function,
and
this
function
configure.
A
I
think
this
does
not.
I
think
this
should
work
with
the
proposal
that
away
has
of
selecting
a
distro
with
a
priority,
because
in
that
case,
what
will
happen
is
that
all
the
distros
are
loaded.
E
A
And
then
the
selected
one
is
just
the
one
that
has
the
highest
priority.
It
has
nothing
to
do
with
this
mechanism,
so
I
think
it
should
work
with
that
as
well.
That's
pretty
much
how
this
mechanism
is
intended
to
work.
E
Yeah,
I
have
a
question
so
if,
as
a
distro
author,
why
wouldn't
I
just
look
into
the
previous
instrument
book
directly?
Instead
of
writing
a
configuration.
E
A
Can
you
can
definitely
do
that
if
you
want
the
pre-instrument
entry
point
is
general
purpose
the.
A
The
reason
why
it'll
be
convenient
to
use
this
is
because,
after
the
the
entry
points
are
loaded
and
all
the
configurators,
I'm
sorry
all
the
computers
are
loaded
or
the
distros
are
loaded.
Sorry,
then
it
comes
the
mechanism
to
select
which
one
will
be
used.
For
example,
here
is
the
current
suggested
mechanism.
That
is,
that
only
one
is
selected.
In
your
case
I
don't
know.
Probably
this
won't
be
necessary
if
we
automatically
select
by
priorities
or
whatever
else
so
so
yeah
I
mean
this
is
something
that
is,
I
mean
the
best
practice.
A
I
guess
to
use
this
entry
point
instead
of
just
using
the
pre-instrument
entry
point,
but
that
that's
also
a
good
point,
because
the
way
I
see
this
these
throws
are
something
that
I
argue
against
them
being
mandatory
for
open,
telemetry
or
instrumentation,
because
these
throws
are
just
the
way
that
we
have
created
to
make
configuration
happen,
and
maybe
somebody
would
prefer
to
use
just
a
configuration
file
or
a
batch
script
or
environment
variables,
whatever
else
or
even
they
may
want
to
have
their
own
custom
main
mechanism
that
just
plugs
into
pre-instrument
and
does
the
configuration
and.
C
All
just
by
looking
at
this
like,
if
I
was
a
distro
author,
like
I
have
to
figure
out
what
this
there's
four
different
entry
points
that
we
have
to
be
used
for
auto
instrumentation
right
now,
right,
there's
only.
C
So
so
this,
like
the
pre,
instrumentation
and
post
implementation
right,
they'll,
be
used
by
whatever
distro
that
I
want
to
create
right
yeah
for
whatever
purpose
you
want
right.
So.
B
C
But
like
if,
if
I
want
like
a
custom
behavior
with
my
distro
right,
do
I
need
to
use
these
pre
and
post
entry
points
to
do
special
stuff?
Okay,
maybe
what
does
what's?
What's
the
difference
between
like
what?
What
okay,
so
now
that
we
have
four
different
entry
points
right?
What
what
is
like
the
logical
barrier
between
them
like
what?
What
are
each
of
them
used
for?
What
do
I
put
in
each
of
them?
Okay,
I
need
to
explain.
C
A
pretty
fine
line
between
configurator
and
distro
only
internally,
like
we
only
kind
of
understand
what
that
is
used
for.
Okay,
no,
no.
A
A
A
The
rest
of
them
are
just
there
are
purple
center
points
or
in
this
or
this
one
is
an
entry
point
for
this.
That's
it
which
are
just
a
configuration,
mechanics.
A
A
C
A
Yeah
the
reason
why
I
introduced
these
entry
points
is
because,
before
we
had
the
open
to
limit
release
through
entry
point
being
executed
before
our
instrumentation
right,
but
it
was
named
as
such,
it
was
they
were
directly
coupled.
A
Our
instrumentation
was
directly
coupled
with
this
first,
because
in
the
in
the
code
that
loaded
the
instrumentations,
there
was
a
specific
call
for
the
disruption
point.
So
they
they
were,
they
were
coupled
together,
and
that
was
something
that
I
mean.
I
guess
it
makes
sense
with
this
idea
that
we
have
that
addition
is
mandatory
for
our
instrumentation
to
work.
A
I
disagree
with
that
and
I
want
to
separate
them
because
I
destroyed
something
that
we
created
to
make
a
configuration
happen
right
and
that's
not
something
that
we
should
force
on
our
users,
because
our
users
may
we
want
to,
as
I
said
before,
configurate
with
a
configuration
file
or
environment
variables
or
whatever
other
mechanisms.
So
these
pre
and
post
entry
points.
A
I
understand
that
they,
it
looks
like
the
pre-instrument
entry
point
is
just
the
confu,
the
disruptive
point,
but
renamed
but
they're.
Actually
not
I
mean
they.
They
actually
separate
the
distro
for
instrumentation.
Now
there
are
two
separate
things.
C
So
I
guess
that's
the
underlying
discussion
point
right
like
do.
We
agree
that
that's
that's
a
compelling
enough
reason
to
add
these,
like,
in
my
opinion,
kind
of
convoluted
and
like
extra
overhead
for
users
to
figure
out
what
this
does.
I'm
already
confused
that,
like
you,
know
everything
I
need
to
do
as
a
distro
author
to
set
up
just
my
you
know,
vendor
specific
customization.
E
So
also
adding
on
to
what
you
can
say,
I
have
a
couple
of
questions
so
so
I
I
understand,
if
I
mentioned
the
the
intention
behind
this
is
to
just
like
conceptually
decouple
the
stores
from
the
instrumentation
package,
but
other
than
this,
as
it
stands
right
now,
it
does
not
solve
the
problems
that
we
were
talking
about
for
the
past
couple
of
seasons.
Okay,.
C
A
Just
just
clarifying
I'm
not
saying
that
this
is
adding
in
direction.
This
is
not
solving
the
problem
of
how
to
select
yeah
at
this
row.
It
is
not
intended
to
solve
that
problem.
C
E
A
So
this
separate,
this
also
contributes,
I
mean,
makes
the
separation
between
instrumentation
and
and
distro,
because,
right
now
we
have
the
base
distro
inside
the
instrumentation
package,
and
so
with
this
idea
here
of
having
a
configurator
packages
separate,
we
cleanly.
E
A
All
the
configurator
code,
in
only
in
one
single
place,
so
the
people
who
want
to
create
a
new
distro,
just
use
the
I
mean
just
need
to
inherit
from
this
class
and
create
their
own
distro.
And
they
can
do
that
for
for
the
approach
that
I'm
suggesting,
which
is
using
environment
variables,
to
select
the
distro
or
the
one
that
you're
suggesting,
which
is
using
priority
numbers,
because
in
both
cases
we
are
seeing
these
these
process
as
a
class.
E
So
so
another
point
I
want
to
get
at
was
if,
if
we
can
figure
out
a
way
to
have
the
same
separation
of
concepts
without
adding
a
new
package,
so
like
the
one
way
would
be,
for
example,
for
the
pre-instrument
entry
point
to
load
everything
it
has
and
then
for
each
pre-instrument
entry
point
to
have
a
attribute
like
let's
say,
type
and
then
group
all
the
entry
points
by
type
and
then
for
each
type
or
each
id.
We
just
load
one
entry
point
I
don't
know
if
I
made
it
made
sense.
E
I
mean
it's:
it's
going
to
achieve
the
same
thing
that
we
won't
have
coupling
between
distros
and
instrumentation
package,
and
we
still
so
it'll
be
still
general
purpose,
but
it
still
gives
us
a
way
to
load
only
one
type
of
like
it
still
gives
us
a
way
to
add
this
logic.
The
logic
that
configurator
has
right
to
the
pre-instrument
entry
point
without
without
having
knowledge
of
destruction.
B
A
I
mean
because
it
has
nothing
to
do
with
pre
and
post
instrument.
I
mean
this.
Pr
is
the
one
that
adds
the
configuration
computer
package,
and
this
is
not
the
vr
that
pre
and
postsystem
their
separate
way.
E
Yeah,
that's
that's
what
I
was
getting
at
that
we,
if
we
just
like
improve
the
pre-instrument
hook
a
bit
and
still
in
general
purpose
code
there.
We
probably
don't
even
need
this
package,
that's
exactly
what
I
was
trying
to
do.
E
I
don't
think
we
do
if
we
like,
add
one
more
feature
to
the
pre-instrument.
Maybe
we
can.
E
E
Yeah
yeah,
they
can
still
be
general
purpose.
For
example,
each
instrument
can
have
metadata.
Let's
say
each
instrument
can
have
an
attribute
that
the
attribute
says
id
or
type,
for
example
right.
So
if
you
instrument
a
distro
and
you
use
pre-instrument
hook,
you'll
set
your
attribute
your
your
type
to
distro
right
and
if
you're,
if
it's
an
instrumentation,
where
we've
support
multiple
ones,
then
each
instrumentation
would
have
its
name
as
the
type
for
example.
E
A
No
no,
no,
but
I
think
that's
I
mean
the
only
thing
that
pre
and
post
instrument
do
right.
Now
is
just
they
call
whatever
is
being
pointed
through
by
the
preamples
instrument.
Entry
point:
that's
it
it's
the
only
thing
they
do.
I
mean
they
don't
try
to
group
things
together
or
anything
else.
A
If
we
start
adding
these
kind
of
features
that
are
targeted
to
the
distro
problem,
then
we
we
stopped
making
this
the
thing
general
purpose
and
we
started
to
make
it
a
specific
purpose,
and
we
start
to
couple
it
with
with
this
one.
This
is
what
we
don't
want
and
we
we
already
have
a
use
case
different
from
these,
throws
that
we
can
solve
with
pre
and
post
instrument
and
is
the
code
that
we
have
of
celery.
A
E
Yeah,
I
think,
yeah.
I
agree.
I
agree
with
everything
you
said.
I
think
there
would
still
be
general
purpose.
They
wouldn't
have
any
specific
knowledge
about
destroyers
or
anything.
Maybe
I'm
not
articulating
myself.
Clearly,
maybe
I
can
comment
on
the
pr
and
like
we
can
take
it
further
there.
It
just
has
an
idea.
We
don't
need
to
like
decide
it
right
now.
Okay,.
A
All
right,
thank
you,
yeah,
yes,
something!
That's.
D
A
Important,
I
I
understand
that
you
see
this
adding
of
a
pre-instrument
entry
point
as
just
making
the
problem.
Sorry
the
the
mechanism
more
complex,
because
we
are
writing
another
step
right.
We
are
writing
a
another
entry
point.
I
understand
that
concern,
but
the
the
what's
happening
right
now
and
something
I
just
mentioned
away-
is
that
we
may
need
this
for
other
stuff.
That
is
not
distro
related.
A
We
already
have
a
use
case
for
that,
which
is
to
remove
the
salary
specific
code
that
we
have
in
instrumentation.
So
I
think
it's
worth
to
have
a
general
purpose
mechanism
to
do
stuff
before
and
after
instrumentation,
because
we
already
don't
because
we
don't
even
know
what
needs
we're
going
to
have
in
the
future.
So
it's
it's
better
to
have
a
general
purpose
solution.
C
Right
so,
okay,
that's
that's
fine,
but
then
we
have
to
treat
this
as
like
a
feature
right.
That's
separate
from
the
discussion
that
was
originally
that
we
were
trying
to
solve
like
the
whole
distro
experience,
how
to
create
one,
how
to
write
one
and
how
it
integrates
with
our
our
sdk
is
the
priority
here.
C
A
Now
this
vr
has
been
separated
because
it
actually
does
not
address
the
the
problem
of
how
to
select
the
display.
I
mean
that's
why
we
separated
this,
and
this
does
not
try
to
solve
the
problem.
I
understand
that
that's
priority,
but
what
happens
is
that
we
write.
We
now
have
an
issue
that
we
need
to
solve
before
getting
into
this
registration
and
it's
the
fact
that
we
have
co-pulled
history
with
our
instrumentation
right
now.
That's
that's!
That's
the
step
we
need
to
take
before
we
get
into
that.
C
C
It's
I'm
posing
this
the
question
to
everyone
right
now,
because
this
is
something
we
gotta
lock
down
right
now
or
quickly,
because
we've
been
spending
two
sigs
on
this
already
and
I'm
like
almost
even
just
as
more
confused
than
I
was
from
the
beginning.
So.
F
I
would
say
that
the
one
thing
that
I've
noticed
that
is
still
a
problem
with
distros
is
that
even
if
other
distributors
write
a
distro
right
now,
the
way
the
distro
code
works
right
now
in
auto
instrumentation.
Is
it
just
picks
the
first
one
that
it
finds?
It
finds
the
distro
that
it
finds
and
it
will
set
that
one
up.
F
So
if
you
have
multiple
distros
installed,
there's
no
way
to
guarantee
that
your
distro
is
the
one
that
gets
picked
up
and
if
you,
if
you
were
to
depend
on
other
distros,
then
you'd
have
to
have
both
of
them
installed
and
in
that
way
you
wouldn't
know
which
one
gets
installed,
but
the
pr
that
we
did
before
to
move
the
code
out
into
the
sdk
helped
with
that.
Because
now
you
don't
need
to
depend
on
the
original
distro
right
now.
F
So
there
is
a
way
for
you
to
have
only
one
dish
installed,
but
if,
if
you
don't,
if
you
have
multiple
distros
installed
right
now,
you
could
the
the
end
result
is
not
defined
right.
It's
based
on
whatever
it
picks
up
first,
so
I
don't
think
that's
a
very
pleasant
experience,
so
that's
probably
something
we
would
want
to
solve,
even
though
we
have
a
workaround
for
it.
C
Yeah,
so
that
that
is
definitely
like
a
problem
yeah,
but
there's
a
different
problem
like
right
now.
The
the
question
I
want
to
answer
right
now
is:
do
we
care
or
is
it
a
problem
that
distros
are
so
tightly
coupled
with
auto
instrumentation
or
better?
Word
is.
If
someone
wants
to
use
auto
instrumentation,
do
they
have
to
have
a
distro
installed.
A
A
Approach,
which
is
to
decouple
things
we
are
not
making
the
user
experience
any
more
complicated,
because
the
the
users
will
still.
D
A
Using
the
the
distro
entry
point,
they
won't
even
realize
that
there's
another
entry
point
and
it
it
makes
it
makes
us
it
makes
our
code
safer,
for
whatever
changes
may
come
in
the
future
because
things
are
decoupled,
I
mean,
if
we
keep
things
coupled,
we
we
make
our
code
more
vulnerable
to
further
problems
that
can
be
caused
by
this.
C
Coupling
that
we're
already
having
so
you're
saying,
like
the
the
distros
themselves,
would
be
using
this
entry
points
right
like
a
separate
entry
point,
which
is.
C
A
Users
won't
even
know
that
the
pre-instrument
entry
point
is
being
there
when
they
use
this
rules,
because
the
only.
A
Is
that
their
distro
hooks
up
into
the
open
telemetry
the
straw
entry
point,
and
that's
it
the
fact
that
the
that
this
entry
point
then
hooks
up
into
the
pre-instrument
entry
point
is
nothing
that
the
users
even
realize
it's
happening.
A
They
don't,
they
only
need
to
know
about
the
the
open
to
limit
release
for
interviewing.
They
don't
have
to
do
anything
with
the
pre-instrument
entry
point,
because
the
open
element
of
the
pre-instrument
entry
point
is
being
called
by
this
open,
telemetry
distro
package
that
we
are
already
providing
so
the
even
that
these
through
developers,
they
don't
even
have
to
know
about
the
pre-instrument
entry
point
so
right
right.
The
user.
C
Okay,
I'd
like
to
hear
from.
G
C
G
C
G
To
to
go
back
to
your
question
laden
around
whether
distros
and
auto
instrumentation
should
be
coupled,
I
I
don't
think
the
auto
instrumentation
should
depend
on
the
distro.
I
I
do
think
that
in
many
cases,
auto,
like
destroyers,
will
be
more
useful
for
auto
instrumentation
but
like
it
doesn't
necessarily
have
to
be
coupled.
So
I
guess,
if,
if
I
had
to
choose
one
or
the
other,
I
would
say
they
should
be
independent
of
each
other.
G
I
I
also
agree
that
it
feels
like
with
the
introduction
of
these
new
entry
points,
and
maybe
it's
just
because
I'm
not
I'm
not
quite
seeing
the
full
picture
of
you
know
who
is
using,
which
entry
point
and
why
or
or
how
they
interact
with
each
other
or
what
the
flow
would
look
like
between
the
different
components.
Here
I
I
do
find
myself
more
confused
about
how
this
is
all
gonna
work
together
than
I
was
like
even
last
week.
G
B
E
E
A
Package
and
this
instrumentation
package
includes
the
base
distro
class.
Okay.
This
is
something
that
we
don't
want,
because
we
want
to
couple
this
okay
now
what's
happening
here,
is
that
the
open
telemetry
instrumentation
process,
which
is
this
black
line?
Has
these
entry
points
represented
by
these
little
circles?
Okay,
and
right
now
this
process.
First,
we
will
first
call
the
distros
right
and
then
we'll
call
the
instrumentations
okay.
A
Now
this
is
a
problem.
We
have
a
separate
problem
of
defining
which
these
throw
we're.
Gonna
select,
okay,
but
that
that's
a
separate
topic:
okay,
we're
not
gonna
get
into
that
right.
What
I
mean
is
that
the
process
itself
of
opportunity
has
that
these
throw
entry
points
like
hardcoded
in
in
itself.
Okay,
the
solution.
A
Providing
is
this
one?
Okay,
so
here
is
in
supplementation
package.
It
has
absolutely
nothing
to
do
with
the
with
the
disk
row
right,
as
you
can
see,
we
no
longer
have.
E
A
Base
distro
class
as
part
of
the
instrumentation
package
they
are
now
separate
and
now
the
instrumentation
process
has
this
entry
point,
which
is
sorry
pre-instrument,
okay
and
then
it
continues
with
the
instrumentation
entry
points.
And
then
here
not
picture
is
the
post
instrument?
Okay.
Now
this
entry
point
is
general
purpose,
okay,
so
what
I
suggest
is
that
we
provide
a
component
named
for
these
throws,
which
includes
the
the
basis
for
class
or
the
default
destroyer,
or
all
the
important
things
that
we
need
for
developing
distrust.
A
Okay,
and
this
component
is
the
one
that
hooks
up
into
the
pre-instrumentation,
but
this
component
also
provides
the
open
telemetry
these
throw
entry
points,
and
then
these
throws
hook
up
into
into
them.
So
the
process
goes
like
this:
it
calls
the
pre-instrument
and
then
the
pre-instrument
calls
the
entry
points
for
this
rows.
Now,
what
I
mean.
E
A
I
say
that
these,
through
developers
would
not
have
to
care
or
they
won't.
Even
they
will
be
blind
to
the
fact
that
we
have
the
pre-instrument
intervention.
It's
because
the
distros
always
hook
up
into
the
open
telemetry
in
the
instrumental
points.
These
ones,
which
are
the
same
as
they
were
called
here,
see
what
I
mean
so
as
far
as
these
three
developers
care.
They
are
hooking
into
this
entry
point
and
they
don't
care
what's
happening
before,
which
is
the
usage
of
the
pre-instrumentation.
A
I'm
sorry,
okay.
I
have
forgotten
that
I
had
this
okay
by
the
way
all
these
things
about
these
environment
variables.
This
is
just
how
I
suggest
that
this
will
be
selected,
but
this
is
again
a
separate
application.
Don't
care
about
this.
A
For
for
instrumentation
itself,
we
don't
need
the.
C
A
C
To
me
now,
okay,
cool
curious
of
how
so
what
what
happens?
If
well,
what's
the
logic
like
when
the
user
doesn't
have
any
distro
installed
but
wants.
E
C
The
default
like
behavior.
A
Okay,
not
having
a
district
installed
yeah
is.
Is
it's
not
the
same
thing
as
having
the
default
distro
installed?
I
mean
in
the
first
case
you
don't
have
any
destroy
at
all.
In
the
second
case,
you
do
have
a
base
installed,
which
is
that
something
called
the
default
one,
so
we
still
have
to
install
a
default
distro.
Not
necessarily.
No.
I
mean
that.
That's
that's
something
that,
with
this
approach,
we
do
not
necessarily
have
to
have
a
default
or
any.
C
Nice,
okay,
so
how
is
the
like,
how
will
things
be
configured
then,
like
instantiated,.
A
C
A
The
net,
the
pr
that
nathaniel
added
added
some
code
to
configure
the
sdk
right
yeah
and
that
kind
of
configuration
is,
as
is
different
from
the
one
that
we
are
intending
to
to
make
happen.
The
districts
these
throws
are
focused
on
vendor
specific
instrument
configuration
and
the
sdk
configuration
is
something
different.
They
are
different
because
the
sdk
configuration
is
defined
in
the
spec
and
the
spec
says.
A
E
A
C
F
A
G
G
G
A
Yes,
something
that
that
we
could
even
do
is
that
we
can
take
this
sdk
specific
configuration
code
and
just
paste
it
in
the
open,
telemetry
instrumentation
code,
so
that
it'll
be
run
before
instrumentation
happens
and
after
or
after
or
before
the
this
open,
telemetry
distro
happens.
D
A
Open
telemetry
instrumentation
mechanism.
D
A
It's
it's
defining
this,
as
everything
else
is.
So
what
I'm
trying
to
say
is
that
this
approach
that
I'm
suggesting
does
not
stop
us
from
making
any
decision
that
we
want
on.
How
do
we
want
the
sdk
configuration
to
happen
this?
This
is
not
not
an
obstacle
to
that.
I
mean
we
can
have
this
and
we
can
still
have.
A
C
So
so,
what's
everyone's
thoughts
about
having
separate
mechanisms
to
configure
the
sdk
and
vendor-specific
things.
A
C
C
Yeah,
I
know
so
I'm
not
opposing
your
solution.
I'm
I'm
trying
to
move
forward
with
the
what
people
will
think
how
we
do
the
sdk
configuration,
because
that's
something
we
need
to
get
answered,
correct,
yeah,
what
I'm
trying
to
say.
C
E
So
what
if,
instead
of
just
instead
of
entry
points,
distros
actually
implemented
the
command
and
like
the
default
destroyer
of
intellimetry
instrument
come
on
and
if
it
is
implemented
distro
it
would
have
to
ship
aways
instrument
command
and
internally.
It
would
subclass
the
open,
telemetry
instruments.
So,
instead
of
entry
points,
we
are
shipping
scripts.
E
B
E
So
so
when
we
say
so,
the
whole
whole
issue
with
entry
points
and
having
multiple
distros
installed,
and
all
this
stuff
comes
out
of
the
issue
that
we
have
a
single
cli
script.
The
open
telemetry
instrument
script
that
we
use
to
automatically
set
things
up
for
the
user
right,
so
that
command
needs
to
figure
out
which
distro
or
configurable
or
whatever,
to
use
and
that's
where
all
this
complexity
is
arising
from.
So
I'm
saying
what,
if
that
command
was
not
part
of
the
instrumentation
package
that
was
part
of
the
distro
package.
E
In
that
case
the
hotel
distro,
the
like
default
distributor
would
contain
that
cli
script
and
if
nathaniel
builds
an
aws
hotel
distro,
it
would
ship
its
own
cli
script
called
aws
instrument
and
edit
this
documentation
would
say
to
its
users,
use
editors
instrument
and
you'll
get
edit
this
pre-configured
distro.
And
if
you
use
the
open,
telemetry
instrument
cluster
to
start
your
services,
then
you
get
the
default
hotel
configuration.
A
Yeah
that
looks
sense,
but
the
problem
I
see
is
that
if
we
make
the
the
open,
telemetry
instrument
command
part
of
the
distro
package,
then
now
we
are
again
copying
this
through
with
instrumentation,
which.
E
Well,
not
neces,
not
necessarily
because
even
if
we
don't
make
it,
we
don't
move
it
to
discharge
and
we
keep
it
in
the
instrument
command.
And
what
is
the
experience
today?
If
people
don't
install
a
default
district
and
they
run
this
command,
the
experiences
probably
nothing
happens
and
the
way
to
fix
this
is
to
add
some
custom
code
that
configures
a
pipeline
right.
A
E
Nathaniel
builds
aws,
elvis
distro
and
let's
say
I
work
on
splunk
distro
and
all
these
starship,
their
own
cla
scripts
and
our
users
use
different
scripts
instead
of
everyone
using
the
same
open,
telemetry,
instrumentation
script
and
then
magic
happening
behind
the
scenes
to
figure
out
which
distribution
is.
People
are
already
making
a
conscious
decision
about
what
to
install
with
pip,
so
they
can
make
a
conscious
decision
about
which
scriptures
that
also.
E
E
E
E
A
Yeah,
I
fundamentally
disagree
because
with
that
approach,
because
if
we
put
the
output
of
limited
instrument
when
in
this
row
again,
we
are
coupling
things
together
and
that's
something
that
that
we
want.
E
Not
okay,
we
don't
we
don't
have
to
put
it
in.
So
I
think
we
can
solve
the
coupling
problem
in
in
many
different
ways,
but
I
was
just
like
what
this.
What
would
this
I
think
as
a
distro
author,
diego,
would
you
be
fine
with
your
users
having
this
experience
and
you
having
to
run
a
light
stuff,
instrumental.
A
No,
I
think
it's
it's.
It
makes
the
experience
harder,
because
now
they
not
only
have
to
develop,
but
this
through,
they
also
have
to
develop
a
command.
It's.
C
E
I
think
look
I
mean
look
at
java,
for
example,
so
java
instrumentation
works
with
the
java
file
right,
so
there's
an
open
terminal,
instrument.jar
file
that
they
have
to
like
hook
when
they're
on
the
java
interpreter.
So
if
there
isn't
there's
a
splunk
or
aws
file,
it
would
be
named
differently
like
it
would
be
named
database
open,
telemetry
java
or
something
dot
jar
right.
So
they
have,
they
would
have
to
change
their
javis
already
do
change
their
cli
arguments
like
the
cli
command.
E
I
mean
assuming
we
we
fixed
the
decoupling
issues.
I
mean
I'm
just
focusing
on
the
ux
and
okay.
A
But
the
the
idea
of
passing
a
cli
option
to
the
open,
telemetry
instrument
command
is
to
be
able
to
select
which.
E
F
F
Really
interesting
and
I
think,
from
a
technical
point
of
view,
it
makes
a
lot
of
sense.
I
just
do
think
from
a
user
experience.
For
me
at
least
I
think
it's
a
little
bit
weird.
I
don't
know
I
I'd
love
to
hear
what
you
guys
think
too,
but
I
like
the
idea
of
how
it
is
right
now,
there's
an
open,
telemetry
instrument
and
everybody
uses
the
same
one
and
it
you
just
install
it
and
you
run
it
and
then
you
add
a
distro.
F
If
you
want
to
configure
it
and
as
we
discussed
the
default,
behavior
will
make
sense
too.
If
it
just
configures
the
exporter.
I
do.
I
do
think
it
starts
to
get
a
little
hard
to
track.
If
you
have
too
many
different
scripts,
you
have
an
aws
script,
the
splunk
script
and
open
telemetry
instrument
script.
I
just
I
like
the
way
that
it
is
right
now
one,
but
I
can
be
convinced
for
your
solution
too.
I
would
say.
C
I
think
I
think
diego
was
right
about
like
the
original
problem.
Does
this
solve
the
original
problem,
which
is
basically,
if
I
was
a
user
without
any
distro
installed,
like
does
auto
instrumentation
still
work.
F
A
Sorry
later,
but
I
think
we
need
to,
I
don't.
A
If,
if
we
have
this
through
install,
if
we
don't
have
a
default
disk
installed,
will
the
open
telemetry
instrumentation
work
with
that
you
mean,
will
the
sdk
be
configured
or
or.
A
C
Guess:
yeah?
Okay!
No!
No!
I
see
what
you're
getting
at
yeah
yeah
okay.
So
so
I
have
a
clear
picture
of
what
diego's
solution
is.
C
Okay,
I
don't
know
about
everyone
else,
but
I
still
feel
like
we
it's
it's
appropriate
to
like
define
very
clearly
what
our
problem
set
is
without
deviating
from
it.
It's
it's
hard
to
do
that
right
now,
at
least
I
don't
really
know
which
ones
are
the
priorities
and
like
which
ones
are
we
trying
to
solve,
regardless
of
anything
like
new
that
we're
trying
to
add
all
in
the
meantime?
C
Still
maintaining
you
know,
user
experience
so
in
terms
of
action
items
so
diego
has
the
you
know
the
pre
post
pr
out
as
well
as
the
refactor
distro.
That
is
one
solution
that
can
go
with.
I
think.
First,
we
still
need
to
maybe
clearly
define
this
problem
set
somewhere
at
least
in
a
discussion
somewhere.
A
A
list
of
all
the
problems
that
we
have,
which
are
separate
like
how
to
configure
the
sdk,
how
if
we
should
decouple
instrumentation
from
these
rows,
how
we
should
select
the
the
distro
if
there
should
be
a
default
or
not,
and
then
pretty
much
like
mark
hpr.
A
A
Yes,
what
format
do
you
prefer?
I
can
open
up
a
discussion.
I
will
suggest
that
open
my
discussion
in
the
indicator.
A
Okay,
how
are
you
doing
that
so
I'll
try
to
make
a
clear
list
of
all
the
problems
that
we
have
and.
C
Yeah
map
them
to
vr,
okay,
good,
sounds
good
we're
out
of
time
now.
I
think
we
still
need
to
dedicate
some
more
time
to
talk
about
this,
but
definitely
moving
in
the
right
direction
and
yeah
any
last
minute
stuff.
Before
we
leave.
E
Is
very
helpful.
I
just
want
to
point
out
that
we
have
just
to
summarize
that
we
have
two
issues
here.
One
is
how
to
decouple
instrumentation
package
from
this
case
and
something
that
might
seem
a
different
problem,
but
I
think
it's
very
related
because
it
has
a
direct
effect
on
how
we
do.
This
is
how
the
default
configurations
applied
in
case
of
distribution
yeah.
I
would
I
would
like
couple
these
two
problems,
because
one
affects
the
other
and
then.
C
C
And
also
how
to
configure
sdks
versus
like
vendor
specific
stuff
as
well
cool
all
right.
Well,
then,
great
discussion
guys
see
you
guys
next
week,
then
all
right.
Thank
you.