►
From YouTube: 2022-05-26 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
Some
people
on
my
team
went
to
the
kubecon
in
europe
and
said
that
it
was
good
and
there's
a
lot
of
interest
in
and
open
telemetry.
But
you
know
a
lot
of
a
lot
of
users
there,
but
not
as
many
community
members.
B
C
A
Oh
bruno
you're
at
red
hat
now,
did
I
get
or
did
I
get
people
mixed
up.
C
Yes,
I
was
company,
so
this
is
my
second
week
at
red
hat.
A
A
All
right
we've
got
a
packed
agenda.
Let's
get
to
it.
I
put
this
on
yeah,
I
actually
just
kind
of
wanted
to
get
jack.
If
you
could
give
us
sort
of
a
overview
of
the
latest
discussions
on
this
and
what
you're
thinking
from
the
java
perspective
sure.
B
Okay,
so
there
are
two
use
cases
at
a
high
level
for
an
api
that
would
be
involved
with
logging.
You
know
traditional
application
logs
or
events,
and
I
guess
just
to
set
some
context
about
the
difference
between
those
you
know.
Events
are
characterized
by
having
a
name
like
a
type
of
event
and
that
that
name
is
guaranteed
to
be
unique
within
a
domain.
B
That
is,
that
is,
is
required
to
be
specified
for
the
the
event,
and
so
so
you
know,
then
they
can
optionally
have
all
the
different
fields
that
are
associated
with
the
log
data
model,
so
they
can
optionally
have
a
severity
they
can
optionally,
have
attributes
and
so
on
and
so
forth,
and
to
so
application
logs.
B
The
the
field
that
is
absolutely
required
is
severity
and
they
typically
have
string
bodies,
and
so
that's
kind
of
the
difference
between
events
and
and
and
application
logs,
and
the
two
use
cases
that
are
being
discussed
are
okay.
So
there
are
a
variety
of
of
reasons
why
we
want
an
event
api.
B
Well,
I
guess
let
me
back
up
a
bit
a
bit
first,
so
so
there's
general
consensus
that
we
don't
want
a
log
api,
especially
because
there's
there's
so
many
log
apis
and
there's
so
much
history
of
log
apis
in
java,
and
so
we
don't
necessarily
want
to
compete
with
those.
But
what
we
do
want
to
be
able
to
do
is
we
want
to
be
able
to
take
logs
from
the
popular
apis.
B
You
know
sl4j
log
back
log4j
and
we
want
to
be
able
to
bridge
those
into
open
telemetry,
and
so
the
use
case
for
a
log
slash
event
api,
for
that
is.
We
need
like
what
what
we've
been
calling
kind
of
a
log,
a
pender
api.
This
is
the
api
that
appenders
use
to
to
bridge
into
open
telemetry,
and
so
you
know
in
log
for
j's
case.
This
is
the
thing
that
you
use
when
you're
writing
the
log
4j
appender
that
bridges
log
for
j
logs
into
open
telemetry.
So
you
need
an
api
for
that.
B
The
the
separate
use
case
is
for
logging
kind
of
events,
and
so
we
do
that.
There's
consensus
that
we
do
want
an
api
for
events.
You
know,
and
the
reasons
are
you
know
there's
there
is
in
contrast
to
application
logs.
B
There
is
no
popular
event:
api,
that's
available
in
the
java
ecosystem
or
in
other
ecosystems,
it's
kind
of
a
new
concept,
or
maybe
not
a
new
concept,
but
the
way
that
we're
thinking
about
events
where
they
they
are
required
to
have
a
name,
and
they
typically
have
a
structured
set
of
attributes.
That
type
of
api
doesn't
really
exist,
and
so
the
conversation
has
been
for
these
two
use
cases.
B
The
log
appender
api
in
the
event
api
are
those
do
those
manifest
as
two
distinct
apis
and
two
different
entry
points
from
open
telemetry,
or
do
we
use
a
single
api
to
satisfy
both
of
those
and
that's
kind
of
what
this
discussion
is
about?
That
trask
has
linked
here.
B
I've
included
two
prototypes
that
illustrate
the
the
two
different
approaches
that
have
been
discussed,
and
so
trask
is
on
one
of
these
and,
if
you
scroll
down
to
at
the
bottom,
there's
like
a
test
class.
That
kind
of
demonstrates
this
a
little
bit
lower.
A
B
This
demonstrates
having
separate
api
entry
points
for
the
log
appender
use
case
and
for
the
event
use
case,
so
you
obtain
an
event
emitter,
and
you
know
you
give
it
your
scope
name
similar
to
what
you
would
give
the
scope
name
for
when
you're
obtaining
a
tracer
or
meter,
but
there's
a
second
required
argument
there,
which
is
the
domain,
and
so
this
reflects
this
this
this
thing
that
we've
been
talking
about
with
events
where
events
are
characterized
by
having
a
name
which
is
distinct
within
a
domain,
and
so
we
force
that
by
having
like
an
argument
here-
and
at
least
that's
been
proposed,
and
that's
what
I've
kind
of
demonstrated
in
this
prototype
and
from
an
event
emitter,
you
can
build
events
and
emit
them
or
well.
B
Let's
see
what
do
I
do?
Okay,
on
28,
through
32,
I
show
like
an
alternative
version
of
obtaining
an
event
emitter,
where
you
include
some
additional
details.
Like
your
instrumentation
version,
you
know
versus
the
shorthand
version
where
you,
you
omit
that
and
then
on
line
35.
We
show
the
simplest
way
that
you
can
emit
an
event.
So
you
you
obtain
an
event
builder,
where
you
name
the
event
and
you
and
you
say,
emit
and
38
through
46
shows
a
more
complex
event
where
you
you
set
some
additional
fields.
B
And
down
on
line
51,
we
show
the
alternative
entry
point
into
the
api,
which
is
this
is
the
log
appender
api,
and
so
you
know
again
reminder
that
this.
This
isn't
meant
to
be.
You
know,
as
a
stand-alone
log
api
that
we
would
expect
people
to
use.
B
We
expect
folks
to
use
the
the
kind
of
more
popular
frameworks
like
slr
for
j
or
log4j,
and
the
appenders
that
you
configure
take
those
logs
that
are
collected
through
those
apis
and
and
and
bridge
them
into
open
telemetry,
and
so
this
is
how
one
of
the
this
is,
how
one
of
those
appenders
would
work.
B
So
you
know
you
obtain
a
logger,
you
build
a
log
record
and
you
emit
it,
and
so
the
advantage
of
this
type
of
approach,
where
you
have
two
separate
api
entry
points,
is
you
have
language
that
is,
that
is
really
unambiguous.
So
you
have
an
event
emitter
that
is
very
clearly
for
emitting
events,
and
you
have
a
log
er.
B
That
is
very
clearly,
for
you
know,
building
and
emitting
application
logs,
so
that
that's
one
of
the
positive
aspects
of
it
and
because
there's
separate
entry
points
you
can,
you
can
have
separate
like
apis
to
obtain
them.
So
you
know
we
talked
about
how
events
have
this
domain,
and
so
you
can
make
that
domain.
A
required
field
when
you're
obtaining
an
event
emitter,
but
not
not
include
that
at
all
in
the
entry
point
for
the
the
logger
portion.
B
So
that's
just
more
more
preciseness
in
the
api
is
the
advantage
of
this
type
of
approach,
but
that
the
downside
is,
you
know,
there's
lots
of
overlapping
concepts
between.
You
know
this
log
appender
api
in
the
event
emitter,
and
so
you
have
kind
of
double
the
api
surface
area,
arguably
with
not
a
huge
benefit,
at
least
some
people
don't
think
so
so,
but
there's
no.
B
You
can
set
a
body
well,
so
I
guess
there's
nothing,
there's
nothing
that
says
you
can't
today.
So
I,
if,
if
you're,
if
you
shouldn't
be
able
to,
then
we
can
reflect
that
in
two
distinct
apis.
But
as
of
now,
you
know,
there's
no
reason
why
you
can't,
although
it's
a
bit
strange.
B
B
So
so
various
folks
have
talked
about
that.
I
know
aws
in
particular,
has.
B
Like
the
concept
of
events,
and
they,
they
have
schemas
associated
with
them
with
required
attributes
that
doesn't
seem
too
dissimilar
to
the
semantic
conventions
that
we
have,
where
you're
required
to
include
certain
attributes,
and
I
imagine
that,
once
those
semantic
conventions
start
to
solidify
for
events
that
the
instrumenter
api
would
start
to
like
encode
those
into
the
attribute
extractors
things
like
that.
To
you
know
the
schema
would
kind
of
be
enforced.
That
way.
D
B
No
events
have
well
so
they
they're
not
that
flat,
because
attributes
have
lots
of
structure
to
them.
Yeah,
that's
a
good
point
and
they
can
have
nested
structure
in
them
too.
So,
like
an
attribute,
you
know
we
don't
we
don't
have
this
today,
but
in
the
in
otlp
attributes
you
know
the
values
can
be
any,
and
so
you
can
have
like.
You
know,
a
map
of
maps
if
you,
if
you
wanted
to
at
the
otlp
level,
although
that's
not.
C
So
one
one
comment:
so:
there's
there's
a
trend
to
structure
logging
with
json
and
isn't
that
the
case
that
we
can
see
those
structured
logs
already
as
events.
B
See
you
could
consider
them
events,
but
in
open
telemetry,
we're
kind
of
we're
kind
of
focusing
in
on
this.
What
what
characterizes
an
event
versus
in
a
law?
A
log
is
the
inclusion
of
this
required
name
field,
and
so,
if
you're
just
doing
standard
structured
logging,
there's
no
the
apis,
don't
sort
of
have
any
any
sort
of
requirement
around
a
name
field
so
that
that's
the
distinguishing
feature.
A
C
So
we
started
with
playing
text
on
logs
and
then
we
wanted
to
have
correlation
between
traces
and
logs.
So
once
you
were
on
a
an
arrest
request,
then
we
know
the
the
trace
when
the
session
would
start.
We
would
add
the
trace
id
to
the
mdc
context
for
that
thread
and
then
all
logs
would
have
that
trace
id.
C
So
you
could
go
back
and
forth
between
traces,
logs
and
so
on,
and
and
this
was
more
useful
when
we
started,
we
transitioned
from
plain
text
to
justin
logging.
So
all
the
fields
are
we
had
to
normalize
them
and
because
the
company
had
a
very
strong
opinion
about
the
the
format
of
the
fields
they
had
to
be
snake
case
because
they
were
json
and
so
on.
C
We
had
to
do
some
transformations
on
the
on
the
fields
themselves,
field,
names,
and
then
this
was
ingested
into
an
elastic
search
thingy
through
kibana.
I
think
and
then
you
could
search
them
and
it
was
well
useful
like
that.
B
So
the
apis
that
we
will
introduce-
I
can
say
this
with
a
fair
degree
of
confidence,
but
that
they'll
be
kind
of
generic
and
non-restrictive
the
semantic
conventions
that
open
telemetry
rights
to
describe
very
specific
things.
Those
will
have
strict
requirements
around
them,
but
you
you
should
and
always
be
able
to
use
the
api
outside
of
that
structure.
C
Okay,
so
will
there
be
a
way
to
to
say
oh
this
field
that
has
this
name
I
want.
I
wanted
to
to
have
this
other
one.
B
So,
okay,
so
the
way
that
the
way
that
this
works
is
you
know
for
typical
application,
logging
use
cases,
let's
say
you're
using
some
sort
of
structured
like
log
back
structured
logging,
api
and
so
you're
you're
you're,
including
a
variety
of
key
value,
pairs
and
you're
logging
that
out
and
you
want
that
to
go
through
the
open,
telemetry
sdk.
So
the
way
that
will
happen
is
we
will
have
a
logback
appender
that
will
take
it.
B
Will
it
will
take
every
log
that
is
emitted
through
logback
and
it
will
bridge
it
over
into
the
open
telemetry
using
the
the
the
appender
api
that
we're
discussing,
and
then
you
know,
depending
on
how
you
configure
the
open,
telemetry
sdk.
That
will
dictate
what
happens
with
that.
I
think
a
common
scenario
will
be
you'll,
use
the
otlp
logger
or
the
otlp
exporter
to
export
those
logs
out
of
your
process
into
some
network
location
like
a
collector.
B
That's
either
running
like
locally
on
the
same
node
or
maybe
within
your
like
your
kubernetes
cluster,
or
something
like
that
once
once
those
are
in
otlp
format,
they're,
very
structured
things.
So
you
know,
otlp
has
a
very
specific
schema
and
you
know
that
the
log
back
appender
will
take
your
key
value
pairs
and
put
them
into
structured
attributes
in
the
otlp
protobuf
payload,
and
you
know
once
it's
in
the
collector.
You
know
the
collector
has
all
sorts
of
utilities
for
doing
arbitrary
mapping
and
transforming
to
do
whatever
you
want.
B
So
you
know
that
that
type
of
use
case
would
is
very
much
possible
in
the
in
the
collector.
B
Well,
so
we
just
haven't,
we
have
inspect
that
type
of
thing
out
yet
right
now,
the
the
specification
for
what
the
open
telemetry
log
sdk
does
is
is
fairly
narrow.
So
you
know
it
should
be
able
to
batch
up
logs
that
are
sent
to
it
and
send
those
to
some
sort
of
exporter
and
there's
only
there's
only
really
one
exporter
that's
defined
at
the
moment,
which
is
otlp,
because
we
don't
know
any
other
standard
protocols
on
where
to
send
those.
We
don't
have
kind
of
a
rich
configuration
language,
like
the
other
logging
frameworks.
B
Do
that
you
know
where
log
for
j
you
can
send
it
to
a
like
a
rotating
file.
You
can
send
it
to
some
database,
etc,
etc,
so
that
type
of
thing
hasn't
been
specified
yet,
and
so
really
we
just
want
to
get
it
out
of
the
application
as
as
simply
as
possible,
and
then
you
know
all
that
tooling
is
built
into
the
collector.
B
A
And
you
could
implement
that
on
in
client
side
today,
if
you
didn't
want
to
do
the
mapping
in
the
collector
using
a
transforming
log
exporter
like
in
the
log
exporter
pipeline,
there's
hooks
where
you
can
filter
and
transform
things
as
they
go
out
to
the
otlp
log
exporter,
it's
programmatic!
It's
not!
You
know
like
a
predefined.
You
know
just
map
this
to
this,
but
it's
possible.
E
B
No,
so
you
know,
as
of
now,
we
don't
want
to
compete
with
other
logging
apis.
We
just
want
to
be
able
to
take
logs
that
are
collected
through
those
apis
and
route
them
through
open
telemetry,
so
th
this
log
api.
It's
it's!
It's
really
a
log
appender
api.
It's
it's
an
api
for
for
to
be
used
by
appenders,
like
a
log
for
j,
appender
or
log
back
a
pender
to
bridge
logs
collected
from
other
frameworks
into
open,
telemetry.
E
It's
more
like
a
bridge
right.
It's
an
ins
in
standard
directive
and
the
user
facing,
or
something
like
that.
F
So
so
jack,
do
you
think
it's
fair
to
say
that
that
is
a
situation
which
is
somewhat
unique
to
us
as
java
folk,
because
my
senses
is
that
in
other
languages,
where
they
don't
have
the
long
history
with
their
say
baggage
of
logging
frameworks
that
we
do,
that
that
might
be
more
of
an
open
question.
Is
that
do
you
think
that's
accurate.
B
That
has
been
the
the
the
mood
of
the
log
sig
is
that
you
know
a
friend
a
language
like
ecosystem,
like
java
shouldn't
be
required
to
provide
a
log
api.
You
know,
because
we
have
so
much
history,
but
in
other
languages
that
don't
have
that
history.
That
language
should
be
allowed
to
provide
like
a
log
api.
If,
if,
if
they're
inclined
to
do
so,.
B
B
So
trask,
I
don't.
I
don't
know
if
you're
interested
in
showing
the
the
other
prototype
to
compare
and
contrast.
B
And
so
the
this
one,
in
contrast
to
the
other,
has
a
single
api
entry
point
that
serves
two
purposes.
It
serves
the
event
api
use
case
and
it
serves
the
log
appender
api
use
case,
and
so
you
know
you
the
simplest
way
to
use.
It
is
to
obtain
a
logger.
You
give
it
your
scope
name
and
that's
illustrated
on
line
23.
B
a
bit
further
down.
This
is
how
on
20
70
31.
This
is
how
something
like
how
you
would
need
to
obtain
a
log
emitter
when
you're
trying
to
emit
events,
because
you
know,
as
we
talked
about
a
domain-
is
a
required
field
on
events,
and
so
you
know
you
have
to
provide
your
your
scope
name
and
then
your
your
domain-
and
you
know
this-
is
illustrating
adding
your
domain
as
a
set
of
scope.
B
So
those
are
those
are
coming
and
so
yeah,
you
obtain
a
log
emitter
with
a
a
name
in
it
in
your
domain,
and
then
this
shows
you
how
to
emit
a
particular
event
named
my
event,
so
you
get
obtain
an
event
builder
and
you
admit
it.
B
This
shows
emitting
a
more
complex
event,
so
you
know
you're,
giving
it
a
name
and
a
set
of
attributes
and
then
finally
down
at
the
bottom.
You
know
you
use
this
same
log.
Emitter
that
you
use
to
emit
events
to
this
is
its
lower
level,
like
log
record
builder,
which
you
use
to
emit
log
records.
B
This
is
the
api
that
would
be
used
by
appenders
like
a
log4j
appender,
and
so
you
know
less
api
surface
area,
because
you
have
a
single
set
of
single
api
entry
point,
that's
serving
two
purposes,
but
less
precise
language
too.
It
may
be
confusing
to
folks
to
use
you
know,
a
log
emitter
or
a
logger
to
emit
events.
F
Of
what's
happening
now,
let's
also
not
forget
that
the
the
audience
for
this
is
somewhat
different
for
the
audience
for
the
other
apis.
We
will
definitely
expect
people
to
code
against
the
tracers
api.
We
would
definitely
expect
end
users,
some
of
them
smaller
subset,
hopefully
to
directly
code
against
the
metrics
api,
but
how
many
people
are
actually
directly
going
to
code
against
this?
A
B
So
that's
kind
of
where
the
discussion
is
at
the
moment.
A
Cool
yeah,
thanks
for
taking
us
through
that
yeah,
you
can
put
me
in
the
plus
one
for
the
separate,
separate
apis.
A
Yeah
and
looking
forward
to
the
events
api
because
that's
been
something
that
I
haven't
been
sure
how
to
explain
to
our
our
customers.
Yet.
D
Yeah,
that's
a
that's
really
interesting
for
us
to
start
thinking
about
how
we
might
be
able
to
map
our
profiling
event
payloads
into
this
new
structure
eventually,
and
I'm
I'm
looking
at,
which
is
why
I
brought
up
like
the
schema
or
this
idea
of
like
a
richer,
more
structured
body
and
thinking
about
our
current
attribute
set.
I
don't
think
that
gets
us
the
coverage.
We
would
need.
D
B
No
so
the
according
to
the
sdk
specifications
attributes
can
only
be
like
primitives
or
array
arrays
of
those
primitives.
B
Yeah,
I'm
I'm
excited
to
start
using
the
event
api
and
some
of
the
jfr
stuff
that
ben
and
I
and
some
others
have
been
prototyping
just
like
lightly.
So
I
think
that's
kind
of
been
a
hold
up
is
that
we
only
really
can
map
this
stuff
to
metrics
and
a
lot
of
those
events
aren't
really
that
useful
as
aggregated
metrics.
A
Oh
yeah,
and
not
to
forget
that
log
api,
when
you
add
that
we
can
rip
out
the
lagapender
api,
we
can
rip
out
the
weirdness
that
we
had
to
do
for
the
java
agent,
bridging
in
in
the
instrumentation
repo.
B
A
Cool
we
have
run
out
of
topics
so
anything
that
anybody
on
the
phone
wants
to
bring
out.
E
I
ask:
I
will
ask
a
silly
question
here
so
in
the
microservices
world
I
I
know
it's
kind
of
sometimes
like
a
service
according
to
service
b.
Sometimes
you
don't
own
the
service
b
and
it
just
yeah
is
hopeful
for
the
best
for
the
scenario.
If
a
service,
a
user
open,
telemetry
service
b
use
open
choosing,
so
if
I
understand
correctly
actually
that
it
won't
be
the
same
matrices
right,
you
like
you,
can't
correlate
these
spans,
so
they
will
completely
disjoint
and
are
correct.
E
Oh,
they
should
be.
Do
we
have
to
do
anything
in
the
like
in
the
background
or
kind
of
auto
boxes,
it
should
work.
A
Well,
which
tracing
distributed
tracing
format?
Are
you
using
the
w3c
trace
context.
E
Is
a
the
format
open,
changing
kind
of
the
older
open
teaching
support?
I
don't
know
whether
answer
your
question.
F
It
kind
of
predates
w3
trace
context.
Doesn't
it
emily?
I
think
I
think
the
answer
here
is
that
is
old
and
dead,
and
they
need
to
upgrade.
I
mean
open
tracing
are
not
doing
any
more
releases
right.
So
the
on
the
answer
here,
I
think,
is
that
they,
you
know
they
they
probably
just
need
to
upgrade
and
to
to
move
to
something
which
is
is
using
w3c,
trace
context
and
and
ideally
open
telemetry
all
the
way
through.
B
We
do
support
ot
trace
propagation,
though
in
open
telemetry,
and
so,
if
trask
is
trying
to
find
it
right
now,
it's
called
the
class
is
called
the
ot
trace.
Propagator.
G
E
E
So
that
would
be
great,
so
then
the
the
scenario
is
yeah
is
we
will
try
to
make
people
push
people
to
upgrade,
but
sometimes
you
know
sometimes
a
different
team.
I
mean
I'm
not
that
lucky
speaker
for,
like
my
own
thing,
like
some
customers,
kind
of
the
they
met
use
the
external
services.
Maybe
the
services
need
time
to
upgrade,
etc.
So
there
will
be
a
scenario
like
a
partial
application,
emotion
on
the
new
things
and
other
betas
still
all
the
technology.
E
If
there's
a
like
the
the
what
a
jack
you
suggested.
So
what's
it
called
open
tree,
open,
telemetry.
B
A
E
C
E
A
A
Just
a
real,
quick
update
on,
I
think
our
the
longest
running
spec
issue
here.
I
think
we
are
like
very
close
here
to
getting
this
merged
jonathan
king
to
me
this
morning.
He
said
he
couldn't
make
it
today
because
of
the
apparently
vmware
is
getting
acquired,
and
but
he
said
he
would
resolve
merge
conflicts
and
I
think
riley
is
sounds
like
he's
prepared
to
hit
the
merge
button.
G
C
C
H
H
G
H
H
G
G
H
G
G
E
E
E
E
So
you
know
how
you
go
to
that
running.
So,
basically,
it's
cdk,
so
all
you
need
to
do.
Is
you
pass
the
zip
and
plus
the
handler?
So
basically
that's
the
entry
point.
So
so
it's
basically
you
need
to
create
another
handler
in
the
in
the
lambda.
Is
there's
a
different
way
to
hook
into
it,
as
you
shown
here,
you
can
do
that
at
a
different
event
or
api
gateway,
or
something
like
that.
E
I
think
what
you
said.
If
you
go
up
a
bit
so
quackers
uses
the
the
stream
uses
the
kind
of
the
also
the
qualcomm
like
a
demo
app,
if
you,
if
you
open
up
the
qualcomm's
demo
app
if
you
go
to
the
the
amazon
source
java
main
you
go
to
go
to
the
left,
just
open
the
yeah
open
up.
E
So
if
you,
if
you
click
on
the
basically
th
this,
it's
a
quickly
into
the
kind
of
this
stream
and
create
a
handler
and
and
also
the
what
is
the
unused
number
with
unusual
so
in
the
interactive
service
process,
click
on
the
processes
processing
service.
E
So
this
is
the
kind
of
cdi
bin.
It's
received
that
you
receive
the
process,
input
stream
and
put
in
the
input
stream.
Can
you
click
on
the
input?
Object?
Implant
object.
E
So
this
is
kind
of
the.
This
is
a
payload
and
there
is.
E
E
So
this
is
the
test.
This
input.
Can
you
click
on
the
integration
test?
That
is
a
package
as
a
lambda
function
there,
but
it
doesn't.
Oh
okay,
so
this
test
is
not
directly
running
as
running.
E
So
when
there's
a
guide,
so
basically
it's
it
will
just
zip
it
up
as
a
zip
and
then
eventually
you
know
a
guide
is
also.
Do
you
have
that
guide
there
yeah
qualcomm's
the
guide,
podcast.
E
E
E
E
Okay,
that
that's
cool
yeah,
so
it's
a
like
so
basically,
okay,
so
it's
a
function!
Dot!
Zip,
yes,
is
a
is
the
way
to
deploy.
If
you
scroll
down
a
bit.
E
Deploy,
I
thought,
there's
a
somewhere
also
is
there's
a
you
need
to
use
the
cdk
as
well,
so
in
this
car
they
didn't.
Oh
it's
directly
to
the
so
where,
where
does
it
see?
The
the
the
hanoi
is
where
the
hanoi
is
and
more
contesting
this
song.
E
Target
I
would
like
to
find
out
where
that
package
is
amazing,
cdk
sdk
or
here
using
the
amsah
java
sdk
version
too.
E
E
E
So
do
you
know
in
the
configuration
it
must
be
somewhere
in
the
quakers
or
somewhere
in
the
configuration?
You
should
specify
the
the
handler.