►
From YouTube: Grafana Community Call 2022-04-21
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
So
welcome
to
the
community
call.
This
is
a
monthly
community
call
for
the
grafana
team,
where
we
share
a
little
bit
about
what's
happening
in
the
grafana
world.
So
this
is
live
right
now
and
I'm
I
really
excited
about
chatting
with
people
about
what's
happening
and
in
plugins
world
specifically
today,
so
this
is
being
recorded.
A
So
if
you
missed
this
today,
you
will
be
able
to
watch
this
after
we
typically
upload
the
video
one
or
two
days
after
it's
been
aired
and
yeah
you
can
access
it
on
youtube,
along
with
all
the
previous
community
calls
that
we've
been
doing,
and
we
welcome
questions
pretty
much
during
the
any
time
of
the
the
call,
we
will
be
doing
a
little
presentation
but
feel
free
to
to
raise
your
hand
there's
a
little
button.
A
I
think
somewhere
here,
that
it
looks
like
a
hand
like
this,
and
if
you
use
it,
you
will
raise
your
hand
and
hopefully
we'll
see
it
and
give
you
the
the
chance
to
to
ask
something.
Also.
We
will
give
plenty
of
time
at
the
end
for
for
extra
questions
that
don't
typically
you
know
not
necessarily
have
anything
to
do
with
the
topic
at
hand.
A
So
this
is
the
plug-in
platform
squad,
so
we
are
doing
a
rotational
schedule
where
every
squad
in
the
grafana
team
is
responsible
for
hosting
the
the
community
call
every
month.
So
you
will
have
different
topics
and
hopefully
get
to
know
a
little
bit
more
about
the
team
and
what
they're
working
on,
and
today
we
have
the
plug-in
platform
team.
This
is
actually
a
pretty
good,
like
good
sized
team.
A
At
this
point,
I
feel
like
it
wasn't
that
long
ago,
since
the
the
team
was
created
and
now
we're
yeah
we're
like
eight
people
now,
unfortunately,
not
everyone
can
make
it,
but
we
definitely
definitely
have
well.
I
think
we
have
half
the
team
teammate
in
here,
at
least
so
that's
awesome
and
yeah.
I
think
we
have
yeah.
Will
we
have
marcus
e
there?
A
We
got
plenty
of
marcuses
in
the
team
and
yeah,
so
I
will
let
each
each
team
member
present
themselves
when
you
know
when
they
get
the
chance
to
present
and
yeah.
B
A
We
get
started
with
the
presentations.
I
have
a
few
things
that
I
wanted
to
share
so
a
few
announcements.
Some
of
you
might
already
be
aware
of
this,
but
we
wanted
to
bring
it
up
again
just
to
make
sure
that
as
many
as
possible
are
aware,
we
are
deprecating
a
few
things.
A
couple
of
things
for
graphona
9.,
the
first
one
being
angular
plugins,
so
angular
plugins
has
been
around
since
I
believe
it's
grafana3
correct
me.
A
If
I'm
wrong
it's
a
long
time
now-
and
you
know
a
lot
of
the
most
popular
ones-
are
angular
plugins.
So
that
is
going
to
mean
that
in
grafana
9
there's
going
to
be
a
flag.
So
by
default
it
won't
actually
load
the
angular
plugins,
but
you
need
to
enable
a
a
configuration
to
actually
load
them.
A
A
So
hopefully
that
will
leave
ample
time
for
plugin
developers
to
have
migrated
over
to
the
react
platform,
which
is
honestly
a
really
cool
platform.
If
you
haven't
tried
it
out
yet
I
highly
recommend
you
switching
over
soon,
but
now
you
got
a
little
extra
fire
under
your
your
seat
there.
Another
thing
we're
deprecating
is
the
the
api
tsdb
query
endpoint,
which
you
can
use
to
make
queries
to
really
any
data
source
as
part
of
the
rest
api.
A
I
don't
know
if
the
team
wants
to
mention
a
little
bit.
Why
and
like
how?
How
big
of
a
change
this
is.
A
I
I
believe
it's
it
shouldn't
be
that
much
to
migrate
should
be
a
fairly
straightforward
change
right.
C
So
api,
slash,
tsb
query:
it's
legacy,
you
can
still
call
it,
but
yeah,
please
stop
using
it
if
you're
using
it.
We
have
been
searching
a
bit
around
github,
for
example,
and
we've
found
a
lot
of
references
to
the
to
the
legacy
endpoint.
So
there
can
probably
be
both
plugins
and,
like
external,
integrations,
using
this
old
legacy,
one,
but
hopefully
by
deprecating.
We
we
should
make
users
aware
of
it,
but
in
regards
to
whether
migrating
from
using
the
legacy
one
to
a
new
one,
it
should
be
very
straightforward.
I
would
say.
C
D
C
Yes,
and
just
one
thing,
maybe
regarding
what
you
said
marcus
before
that
you
use
this
to
query
any
data
source,
I
would
just
like
to
add
that
that
is
any
backend
plugin
data
source.
A
So
thank
you
for
that.
Another
thing
I
want
to
highlight
is
that
we
have
been
writing
a
ton
of
guides
if
you're
not
familiar
with
the
the
let's
see.
If
we
can,
I
can
show
you
there
is
the
community
grafana.com
site
if
you're
not
familiar
with
it.
In
there
we
have
a
plugin
development
category
for
all
things,
plugin
development.
A
Here
you
can
ask
questions
on
plugin
development
and
the
the
new
thing
that
we've
started.
Doing
now
is
that
we
have
this
new
sharing
showcase,
where
both
the
team
is.
Writing
healthy.
You
know
helpful
tips
and
tricks
on
plugin
development,
but
we're
also
seeing
if
you're
writing
a
new
plugin
and
you
want
to
share
with
the
community,
maybe
how
to
use
it,
what
it's
good
for
and
so
on
feel
free
to
to
post
there
and
tell
the
world
about
it.
A
But
there
are
already
quite
a
few
guides
in
here
for
how
to
use
docker
when
you're
developing
plugins
how
to
debug
your
backend
plugin
and
a
lot
of
good
stuff.
So
we
try
to
add
more
as
we
go
along.
We
try
to
keep
track
of
what
people
are
asking
about,
and
you
know
common
troubleshooting
things
that
people
struggle
a
little
bit
with.
We
try
to
to
include
it
here.
A
And
might
also
add
that
the
team
has
been
busy
adding
a
few
more
plug-in
examples.
A
So
please
check
out
the
the
plug-in
the
grafana,
slash,
grafana,
plug-in
examples
repository
here,
so
we've
been
adding
a
few
more
if
you're
interested
in
app
plugins
you'll
be
pleased
to
know
that
there's
a
there's
a
example
there
for
for
app
plugins
as
well,
so
feel.
A
Well,
I
hope
it
will
be
useful
to
you
by
now.
I
I
know
that
you're
you're
ahead
of
the
curve
you've
already
developed
a
few
of
your
own,
but
this
is
great
for
for
just
getting
started.
A
So
I
think
on
to
the
next
topic,
which
is
going
to
be
reducing
unintentional,
breaking
changes
in
plug-in
apis,
so
this
is
something
that
we've
been
working
on
lately
for
past
few
months,
especially
I
think
q4
was.
This
was
a
big
topic
for
us
and
marcus
is
going
to
oh
perfect.
F
C
Great,
so
breaking
changes
a
bit
of
a
background
first,
so
one
of
the
major
goals
for
our
squad
in
q4
2021
was
to
find
a
way
to
deal
with
breaking
changes
in
grafana
front
and
plug-in
apis.
C
C
But
what
I
basically
want
to
summarize
it
with
was
that
was
a
lot
of
discussion
towards
end-to-end
tests
or
integration
tests,
but
in
general
that
would
require
so,
given
that
we
would
like,
when
we
do
changes
to
grafana,
we,
we
would
like
to
basically
run
checks
in
put
requests
to
to
get
an
idea
of
whether
exchange
is
breaking
any
plugins.
C
So
given
like
end-to-end
tests
or
integration
tests,
that
would
basically
require
all
plugins
to
implement
intent
tests
and
with
all
plugins
I
mean
all
community
plugins,
and
with
that
we
would
have
to
run
those
in
a
simple
manner
on
each
pull
request
in
grafana,
which
is
not
really
trivial
and
quite
hard.
C
C
C
C
C
So,
for
example,
if
you
have
removed
any
exported
members
in
a
package,
you
will
get
a
detailed
view
of
all
the
removals
that
has
happened,
so
that
would
be
a
breaking
change
and
whether
an
existing
member
has
been
changed.
That's
also
a
breaking
change
and
levitate
will
also
show
that,
but
if
there's
no
additions,
removals
or
changes,
that
means
basically
no
breaking
changes.
C
All
right
so,
besides
running
levitate
continuously
on
all
pull
requests,
we
are
actually
also
collecting
information
about
what
apis
the
plugins
in
our
plugins
catalog
uses.
C
C
So
the
possible
future
steps
of
this.
We
probably
want
to
add
more
information
to
put
requests
in
rafana,
for
example,
how
many
plugins
will
be
affected
by
the
change
or
exactly
which
plugins?
B
F
C
So
currently,
it's
only
used
in
grafana
itself.
Okay,
that's
why
I
put
it
under
possible
future
steps
to
offer
its
plug
developers,
but
with
that
said,
you
could
basically
use
levitate
with
this.
Currently,
I'm
not
sure
if
that
answers
your
question,
but
basically
the
story
around.
What
you
want
to
do
is
part
of
our
future
ideas.
A
I
I
just
have
a
one
question
then,
so
the
the
workflow
that
you
could
potentially
do
today
is
that
you,
as
a
plugin
developer,
you
use
levitate
on
your
machine.
Just
to
you
know
see.
Is
there
anything?
I
should
be
aware
of
right.
I
could
do
that
today.
It
might
not
check
my
specific
plugin,
but
I
could
already
today
check
using
levitate
breaking
changes
between
two
versions
of
grafana
toolkit,
correct.
A
You
go
back
to
your
screenshot
you're,
comparing
two
versions
of
rafana,
so
I
could
do
that
just
to
get
like.
Let's
say
that
my
plugin
is
using
grafana
8.1.3
and
I'm
considering
my
upgrading
to
the
latest
version,
but
I
want
to
know
ahead
of
time
whether
something
is
going
to
break
so
I
could
do
that
already.
Can
I.
F
But
it's
all
manual
right,
so
you
kind
of
have
to
know
what
you're
looking
for
to
understand.
That
is
that
I
mean,
but
can
you
do
something
because
right
now
I
mean
a
lot
of
plugins
developed
for
version
seven
and
for
the
iteration
right.
You
always
appreciate
some
kind
of
like
location
services,
for
example,
which
was
appreciated.
F
C
I
guess,
but
our
hope
is
to
automate
this
and
provide
this
to
plugin
developers
eventually,
so
that
you
don't
have
to
do
anything
manually
right.
Wait,
for
example,.
F
Okay,
the
problem
is
right.
Now
it's
a
plug-in
development.
You
in
the
change
lock,
you
can
see
everything
is
a
high
level
what
changed
actually,
but
as
soon
as
you
started
to
develop
like
I
have
some
plugins
applications
which
use
low
code
functions,
you
never
know
what
it
breaks
unless
you
kind
of
test
it
with
that
early
release
and
it's
time
consuming.
G
C
Yeah,
I
can
totally
understand
that,
but
that
makes
me
think
that
maybe
we
should
start
using
levitate
in
our
releases
to
actually
extract.
C
D
One
thing
I'd
like
to
mention,
too,
is
like,
as
part
of
this
whole
initiative,
that
max
mentioned
that
we
kicked
off
last
year
was
kind
of
figuring
out
in
general,
like
how
we
ended
up
in
a
place
where
we're
constantly
breaking
things
and
what
we're
hoping
and
one
of
the
most
conscious
things
where
we're
trying
to
do
is
as
well
as
this
tool
is
like
stop
doing
that
like
stop
having
patch
releases
where
we
break
something-
and
this
is
the
tool
that
stops
that
so
hopefully
miguel
you
won't
see
like
oh,
I
just
have
to
update
the
patch
version,
and
this
little
thing
I'm
using
is
now
broken.
D
C
C
All
right,
so
I
guess
moving
on
to
the
next
topic,
which
is
a
little
bit
related.
I
guess
so
with
the
plug-in
examples
that
marcus
mentioned
before
we've
actually
added
a
couple
of
integration
tests
right
there.
C
C
So,
let's
see
here
we
have
basically
the
panel
basic
and
data
source
basic,
including
integration
tests.
Right
now
I
will
jump
into
them
in
a
sec,
but
the
panel
basic
includes
some
tests
for
viewing
or
editing
panel
using
screenshot
comparison
and
the
data
source.
Basic
plugin
has
tests
of
configuring
and
clearing
a
data
source.
C
C
So
in
this
example,
we
have
a
test
viewing
a
panel
with
time
series
data.
It
should
display
a
good
looking
graph
and
I
guess
it
does
its
magic
to
find
the
panel
and
take
screenshot
of
it,
and
then
it
will
compare
the
screenshots.
C
C
There
is
a
screenshot
to
compare
with
stored
since
before
so
when
you
run
it
again,
it
will
be
compared
to
to
an
earlier
one.
C
So
that's
the
whole
idea
with
with
comparing
screenshots
these
tests
and
there's
similar
one
for
editing
a
panel
which
is
similar,
the
other
one
data
source
basic
doesn't
do
any
screenshot
comparison,
it's
more
more
like
unit
tests,
but,
as
marcus
said,
an
actual
web
browser
is
spun
up
together
with
with
grafana,
so
we
basically
navigate
inside
rafana
and
in
this
example,
you
can
test
by
configuring
your
data
source
like
a
configuration
interface
and
assure
that
that
works
as
expected.
C
C
C
C
Secondly,
we
run
it
against
the
latest
stable
version
of
grafana
and
thirdly,
the
latest
canary
packages
and
latest
canary
version
of
grafana,
since
that
allows
us
to
catch
bugs
and
toolkit
and
then
to
end
packages
or
runtime
errors.
Optica
not
picked
up
by
levitate,
and
so
we
can
have
a
look
at
this
example
as
well.
C
C
C
Given
the
next
steps
that
I
will
will
soon
mention,
but
this
could
also
help
the
graffana
developers
understand
if
braking
change
has
been
introduced
in
case
that
levitate
didn't
catch,
that,
for
example,
so,
regarding
the
next
steps,
the
integration
test
for
the
plug-in
examples
is
something
that
would
like
to
run
regularly,
maybe
each
day
or
something
like
that
to
spot
any
issues
with
breaking
changes
and
then
again
regarding
plugin
developers.
C
And
yes,
here
are
some
additional
information
that
you
can
find.
I
mentioned
you
could
run
end-to-end
tests
in
different
way,
different
ways,
and
that
would
be
in
these
guides
here,
and
I
guess
this
is
probably
something
we
should
try
and
migrate
to
the
actual
documentation
not
having
it
in
the
graphon
repository.
C
F
C
As
I
said,
we
would
like
to
provide
an
outdoor
box
experience
for
plugin
developers
just
use
an
existing
github
action,
for
example,
but
if
you're
interested
to
do
this
now,
you
should
be
able
to
based
on
the
git
of
actions.
Workflow
specification
here
should
be
able
to
come
up
with
something
similar
for
your
plugin.
H
So
one
important
thing
to
note
for
the
the
cypress
test
is
to
have
stable
data,
so
you're
querying
a
data
source
and
it
returns
different
data
every
time
or,
if
you're
doing
like
last
30
minutes
or
something
you'll
get
different
screenshots,
so
it'll
be
very
frustrating.
B
H
Up
with
some
fixed
queries
and
you'll
always
know
the
results,
so
your
your
panels
will
be
easier
to
test
that
way.
That's
it's
probably
been
the
biggest
challenge
we've
had
for
a
data
source
and
end-to-end
tests
is
having
that
stable
data
set
and
trying
to
query
a
real
backend
and
not
mock
the
back
end
completely.
H
C
But
now,
since
we
talked
about
it,
I
would
say
it's
somewhat
related,
it's
not
really
the
same,
and
so
I'm
in
the
grafana
plug
in
sdk
go
now
experimental
package.
Something
that's
been
are
being
worked
on.
Is
this
idea
of
http
traffic
logger,
which
is
currently
right
now
for
local
debugging.
C
C
But
when,
when
we
talked
about
this
a
little
bit,
I
can't
think
about
end-to-end
tests
like
it's
quite
tricky,
to
to
do
end-to-end
tests
with
data
source
plugins
or
at
least
from
grafana's
perspective.
If
grafana
would
like
to
run
end-to-end
tests
for
a
lot
of
different
plugins,
maybe
all
the
community
community
plugins
so
like.
C
C
Handling
that
is
happening
like
between
a
request
coming
into
to
grafana's
api
and
back-end
data
source
being
called
processed
and
returned
data
frames
like
what,
if
we
can
cut
that
middle
step
and
just
return
data
directly
for
this
http
api.
So
that
could
be
a
way
to
to
write,
enter
and
test
for
data
source
plugins
to
test
the
actual.
D
In
eight
five,
obviously
so
I
was
discussing
with
the
author
today,
his
name
is
todd
he's
on
a
different
team
he's
on
the
observability
squad,
but
he's
been
working
on
this
and
we're
hoping
to
get
it
in
a
patch
of
eight
five,
I'm
not
sure
exactly
how
usable
it
is
in
its
current
state,
but
at
least
in
eight
five
one
we're
hoping
to
make
it
pretty
straightforward
out
of
the
box,
and
you
can
see
even
in
this
reading
here.
D
C
A
So
it
feels
like
you
know,
you
might
ask
yourself
like:
why
are
we
doing
all
this
to
catch
breaking
changes?
Aren't
we
the
plug-in
platform
squad?
Doesn't
it
like?
Aren't
we
the
one,
that's
actually
developing
the
plug-in
platform
shouldn't?
We
be
able
to
see
this,
but
I
I
think
the
the
important
part
here
is
that
the
the
api
is
actually
developed
by
the
holographana
team.
So
we
have
observability
squads.
A
We
have
the
user
essential
squad.
We
have
several
squads
that
are
all
working
on
this
and
we
want
to
catch
anything
that
affects
you
know.
If
one
squad
adds
or
changes
the
api
we
want
to
detect
whether
that
is
compatible
with
a
change
that
another
squad
has
done.
So
I
you
you
might
think
like.
Why
are
we
even
doing
this
and
it's
it's?
It's
a
it's
tricky
to
keep
track
of.
You
know
all
the
changes
that's
being
made
throughout
the
entire
grifana
team
and
making
sure
they're
all
working
together.
A
A
Hopefully,
we'll
we'll
see
less
and
less
of
these
braking
changes
or,
I
should
say,
unintentional
breaking
changes.
Obviously,
there
are
going
to
be
some
breaking
changes
in
you
know
in
the
future,
in
order
to
keep
innovating
and
to
keep
improving
grafana,
but
we
want
to
make
it
intentional.
We
want
to
anytime,
we
make
a
breaking
change.
We
want
to
have
clear
documentation,
we
want
to
be
able
to
tell
you
exactly
how
to
mitigate
it
and
what
to
do
instead
and
we
also
be
wanting.
A
We
want
to
be
really
clear
about
what
value
that
breaking
change
brings.
So
we're
not
just
breaking
things
for
the
sake
of
it.
So
it's
definitely
a
big
step
in
being
a
little
more
responsible
for
what
we
do.
F
That
makes
sense
is
I
know
that
grafana
9
is
coming
right
and
it's
kind
of
it
will
be
on
grafana
con
when
it's
going
to
be
released.
Is
it
going
to
be,
but
there's
going
to
be
no
private
release
right
before
how
we
can
get
prepared
for
what
is
covering
the
final
line.
A
A
A
Yeah,
if
you
use
the
docker
image
for
the
the
main
tag,
you
should
get
the
most
up-to-date
one.
So
if
you
want
to
try
it
out,
use
that
one,
but
there
yeah
we,
we
are
gonna,
create
the
tag
before
grifanacon,
but
you
should
be
able
to
use
it
from
any
any
tag.
We
publish
on
docker
hub.
A
Well,
we're
currently
working
on
a
a
number
of
features
that
might
not
be
merged
yet,
but
as
we
get
closer
more
and
more,
we'll
obviously
get
done,
and
some
of
it
is
behind
feature
flags
already,
but
not
quite
there.
Yet
I
believe
so.
Yeah.
A
You
know
we
we
don't
like
of
just
working
in
secrecy
and
then
just
do
a
big
bang
release
and
then
see
what
everyone,
how
it
crashes,
people's
environments
we
want.
You
know
we
want
to
develop
grafana
in
the
open,
and
you
know
all
the
all
the
commits
to
the
main
branch
is
going
to
be
published,
so
you
can
run
it.
E
C
C
E
Also
say
from
painful
personal
experience
like
maine
is
main.
I
would
not
run
that
in
like
if
it's
let's
say
that
you
have
something
that
you
would
care.
If
the
meta
database
got
corrupted
not
a
place,
I
would
run
maine
straight
with
that
very
good
point.
F
D
F
D
Thanks
to
the
tooling
and
all
the
testing
stuff
we
have
now
in
place,
so
I
would
hope
that
yeah,
we
we're
not
in
a
place
where,
all
of
a
sudden,
you
hit
the
stable
version
for
nine
and
something's
broken,
it
should
be
really
crystal
clear
what
has
changed
in
the
api
and
how
that
affects
your
plugins
and
you're,
based
on
the
feedback,
even
just
listening
today,
of
the
questions
you
ask,
I
think
it
gives
us
some
good
ideas
of
what
we
can
set
to
put
in
place
by
using
some
of
these
things
together
to
share
with
people
to
say,
hey
run
this
just
before
you
know,
we
released
this
thing
to
the
world,
to
give
you
a
clear
idea
of
how
your
plug-in
is
affected.
F
F
C
A
C
Yeah,
we
actually
have
one
c-sharp,
which
maybe
not
many
are
aware
of,
but
the
image
renderer
plug-in
is
written
in
typescript,
but.
C
So
with
the
image
renderer,
we
had
to
use
some
packaging
thing
to
bundle
everything
together
in
a
single
binary,
but
that
has
also
been
very.
C
What
do
you
say
fragile,
I
would
say
so,
but
yeah
it's.
There
is
a
repository
as
marcus
mentioned
and
we're
not
officially
supporting
it,
but
you
can
do
it
if
you
want
to
live
on
the.
A
Screen
I
I
should
add,
though,
that
we're
currently
not
considering
plug-in
backend
plugins
written
in
any
other
language
then
go
for
publishing
to
graphone.com
and
the
reason
being
that
go
is
really
nice.
A
That
way,
you
get
you
compile
it
down
to
like
a
single
binary
that
you
can
run
without
any
dependencies,
whereas,
if
you're
building
a
plugin
using
java,
for
example,
then
our
grafana
cloud
instances
need
to
run
a
specific
ver,
specific
version
of
java
or
c-sharp
or
like
any
any
language
that
you
choose
essentially
python,
for
example,
and
we
would
have
to
do
the
version
management
of
that
essentially,
so
I'm
we
currently
don't
have
any
plans
of
supporting
any
other
languages.
A
For
that
reason,
on
griffon.com
I
should
say
obviously,
if
you're
developing
internal
plugins
within
your
organization
by
all
means
go
go
nuts,
it's
grpc,
you
implement
it
in
any
language
you
feel
like,
but
currently
we
we
don't
have
any
way
of
publishing
it.
If
you
want
to
make
it
public.
E
Yeah,
if
you
have
michelle,
if
you
have
the
brilliant
solution
to
this,
we're
all
ears
but
we're
what
we've
seen
so
far,
it's
just
gonna
be
a
lot
of
work
and
we
haven't
gotten
to
that
work.
Yet.
F
I
mean
for
me
I
we're
talking
with
these
marks
about
it.
Already
that
I
mean
I
started.
If
I
start,
I
have
an
idea
about
data
source
plug-in.
I
normally
start
with
the
front-end
part
only
because
so
easy
to
prototype
it,
and
then,
if
it's
something
interesting,
I
want
to
do
or
it's
only
can
be
done
using
backhand.
I
use
the
go,
but
it's
I
mean.
If
you
use,
I
mean
I'm
liking
for
typescript
only
because
it's
kind
of
same
experience,
what
you
do
on
the
front
end.
F
You
know
what
you're
doing
back-end
you
have
the
same
classes.
You
have
everything
kind
of
because
right
now
you
do
quite
the
job.
You
spend
twice
the
time
to
do
the
goal
and
then
for
the
front
of
the
park.
So
it's
certainly
with
the
typescript.
It
will
be
easier
to
streamline
and
with
the
node
node
is
not,
I
mean
for
me,
it's
not
a
problem,
because
if
you
run
it
in
docker
in
container,
you
normally
have
a
docker
there
on
node
right.
You
can
install
it.
A
A
Transcript
it's
it's
obviously
not
trivial,
to
ask
a
plug-in
developer
to
learn
two
languages
for
a
lot
of
developers
out
there
they're
they're,
they
have
their
hands
full,
just
learning
one
language.
A
So
we
definitely
understand
this,
and
we
like,
like,
like
jay
mentioned,
we
we
are
considering
this
internally
and
how
we
want
to
approach
this,
because
just
merely
from
a
developer
experience
perspective
and
making
it
easier
to
build
these
plugins.
G
Yeah
well
I'd
just
like
to
add
something
down
just
on
one
week,
I'll
say
this
like
yeah,
we
we
use
typescript
internally
to
build
our
plugins
and
it's
quite
useful
to
know
about
the
sort
of
the
situation
with
go
and
how
you
guys
want
that
from
a
publishing
point
of
view,
so
very
useful
to
know,
as
I
say,
we
use
typescript,
because
it's
just
much
easier
for
us
in
terms
of
getting
developers
who
can
actually
get
started
on
that
it's
just
easier
and
then,
of
course,
if
we
have
to
go
to
go
later
on,
then
you
can
make
that
decision.
A
A
A
Yeah
obviously
alerting
is,
is
very
attractive
for
a
lot
of
people.
F
Yeah,
that's
right,
but
I
I
just
wanted
to
mention
that
I
mean
when
you
look
into
this
typescript
and
go
it's
easier
when
you
do
only
get
when
you
only
receive
the
data,
but
what
we
started
to
do.
A
lot
later,
usually
doing
delete
post
and
put
to
modify
the
data
and
it's
kind
of
very
time
consuming
to
do
both
parts
for
that.
So,
which
is
why
typescript
will
be
the
best.
A
Well,
thank
you
so
much
for
sharing
it
it.
It
really
helps
us
understanding.
You
know
you
sharing
how
you're
using
the
api
really
helps
us
understand
what
we
should
focus
on
and
it's
it's
super
helpful.
So
I
really
appreciate
you
letting
us
know
and
another
way
of
you
know
you
don't
have
to
wait
all
the
way
to
next
time.
A
The
plugin
platform
hosts
me,
the
the
community
call
you
can
head
either
into
the
the
plugins
channel
on
our
slack
team
or
you
can
head
to
the
community
forum
as
well,
and
if
you're,
we
obviously
would
love
to
hear
how
you're
using
the
plugin
api
and
what
struggles
you're
facing
and
obviously
we
want
to
try
to
help
you.
But
you
know
we
understand
that
not
all
the
things
that
are
you
know
supported
at
the
moment
so,
but
we
still
want
to
hear
them.
G
I
don't
want
to
sort
of
it's
not
sort
of
specific.
It's
about
a
specific
plug-in.
That's
on
the
system,
which
is
we're
trying
to
do
non-linear
histograms,
but
we're
passing
in
data
that
is
sort
of
in
pre-computed
buckets,
and
it
doesn't
seem
to
be
a
way
of
doing
that.
A
So
I
think
this
is
actually
something
that
I
would
love
to
know
about,
that
people
are
asking
for
it.
Jay
do
you
know,
I
think
it's
leon
right.
The
edge
team
working
on
it.
E
Yeah,
I'm
not
close
to
the
latest
work
on
that,
but
this
is
a
great
question,
so
I
will
go
and
dump
it
in
the
right
people's
lab
and
we'll
see
what
what
comes
of
it.
Yeah
cool.
F
My
client
actually
asked
me
to
maybe
rewrite
the
histogram
panel
because
he
doesn't
like
whatever
you
have
right
now.
So
if
you
can
get
this
feedback
to
you
and
improve
the
histogram
files,
so
we
don't,
we
don't
create
anything.
Ourselves
will
be
great.
I
can
get
the
feedback
from
the
client
what
you
want.
A
So
I
could
add
another
thing:
we
we
recently
had
a
a
new
panel
plug-in
published
called
the
mosaic
plot.
It's
on
the
underground.com
right
now.
I
I
don't
know
if
that's
supported
in
it,
I
would
have
to
check
closer
but
yeah.
If
that
you
I
would,
I
would
recommend
that
you
look
into
that.
One.
B
A
Is
a
it's
a
it's
a
really
cool
plug-in,
pretty
feature-rich,
I
would
say
I
can
drop
a
link.
A
A
Okay
with
that
we're
coming
up
on
the
hour,
thank
you
so
much
for
joining
us.
It's
been.
It's
been
great,
a
lot
of
good
feedback
that
we'll
definitely
take
with
us
and
again
this
will
be
uploaded
to
youtube.
So
if
you
had
any
teammates
that
couldn't
attend,
feel
free
to
link
it
to
them,
we'll
you
know
just
visit
our
our
youtube
account
and
there
will
be
a
playlist
with
grafana
community
calls.
You
can
find
it
there.
A
So
I
will
say
next
month
the
observability
experience
squad
will
talk
about,
explore
and
and
and
features
related
to
it
so
check
back.
If
that's
interesting
to
you
and
yeah
I'll,
see
you
next
time.
Thank
you
all
for
joining.