►
From YouTube: Grafana Agent Community Call 2022-07-20
Description
Talked about the development and timeline of flow.
A
All
right
welcome
everybody
to
the
igrifana
agent
community
call.
It
is
july
the
20th
yeah,
so
we'll
take
a
look
at
the
topics
and
just
work
through
them.
If
anyone
has
any
thing
that
they
would
like
to
ask
or
jump
in
or
have
any
conversation
about,
feel
free
to
either
bring
it
up
either
by
talking
about
it
typing
in
the
chat
or
any
other
means
that
you
would
like
to
the
first
topic
we
have
is
to
address.
A
All
right
and
we'll
jump
into
an
update
on
grafana
agent
flow
I'll,
give
just
a
little
bit
of
flavor
around
that
fondant
agent
flow
is
something
we're
experimenting
and
looking
into
making
a
new
type
of
configuration
that
focuses
more
on
component
kind
of
like
legos,
that
you
connect
together
to
create
a
workflow
of
how
metrics
or
logs
or
anything
else,
eventually
will
flow
through
the
system.
It's
currently
in
a
highly
experimental
mode
and
will
definitely
be
something
we're
soliciting
a
lot
of
feedback
from
the
community.
A
There
are
several
rfcs
out
there
and
we're
just
bringing
it
up.
Kind
of
you
can.
Look
at
previous
community
calls
to
see
some
other
presentations
that
we've
done
about
it
and
everyone's
free
to
jump
in
the
community
agent
flat
channel
and
bring
it
up
at
any
time
and
we'd
be
more
than
happy
to
talk
about
it.
I
will
turn
it
over
to
robert
to
talk
a
little
about
the
timeline.
B
B
So,
like
really,
the
plan
is
to
release
something
completely
opt-in,
completely
experimental
that
we
want
to
collect
feedback
from
users
from
and
over
time,
iterate
on
it
and
slowly
work
towards
the
decision
point
of
should
this
replace
the
current
agent
and
at
any
point
during
this
process,
we're
going
to
allow
ourselves
to
say
this
is
bad.
This
isn't
good
and
just
back
pedal
all
the
way
back
to
like
what
we
have
today
and
keep
it
there.
B
B
B
Then
we're
we're
giving
ourselves
four
releases
to
collect
feedback
and
iterate
as
much
as
we
can.
This
might
change,
but
I
think
four
releases
four
months
is
a
pretty
good
kind
of
timeline
to
get
a
better
understanding
of.
If
people
like
this
or
not,
then
after
that
two
releases
after
that,
after
it's
stable,
we'll
we'll
kind
of
deprecate
the
existing
mode.
If
that's
what
we
decided
to
do
and
then
have
flow,
be
the
default
by
the
way
I
kind
of
skipped
over
it
once
flow
becomes
stable.
B
We
ship
it
with
migration
tooling
to
allow
you
to
change
from
the
current
agent
config
into
the
flow
configs,
so
by
the
time
flow
becomes
the
default
you
already
should
have
migrated,
but
if
you
hadn't,
the
tooling
is
still
there
to
easily
migrate
with
the
deprecated
stuff
or
from
from
the
deprecated
things
towards
flow.
Then,
after
it's
deprecated,
it
follows
the
normal
deprecation
schedule
of
two
releases
of
deprecation.
Then
then
removal
so
after
that
in
0.35.
B
B
I
also
think
that
35
minor
releases
every
every
six
ish
weeks,
probably
is
a
good
indicator
that
we're
ready
for
one.
That's
a
separate
discussion,
I'm
I'm
personally
looking
out
for
when
we
do
this
the
wanna
release,
but
this
is
the
timeline.
I
think
this
gives
us
a
lot
of
time
to
collect
feedback
and
a
lot
of
time
to
understand.
If
people
like
what
we're
doing
so,
I'm
I'm
hoping
that
by
the
27
release,
we
we
start
getting
feedback
and
have
confidence
a
lot
earlier
than
than
having
to
wait
until
december.
B
B
B
Is
this
something
we
want
to
continue
forward
and
mark
it
as
a
stable
thing
or
something
we
want
to
back
away
from
see?
I
think
performance
functionality
like
it
should
be
one-to-one
equivalent
with
the
agent
by
the
time
it's
stable,
like
flow
should
do
at
least
what
the
agent
does,
if
not
more,
but
when
I
say
the
asia,
it's
still
the
agent,
but
flows
like
a
different
mode.
So
the
you
know
flow.
B
The
flow
mode
should
be
functionality
equivalent,
if
not
having
more
functionality
compared
to
the
current
agent,
the
static
mode
as
we're,
calling
it
functionality,
performance
and
and
generally
positive
reception.
You
know
a
good
positive
to
negative
ratio
would
be
kind
of.
You
know
the
three
factors
I'm
paying
attention
to.
B
A
A
System
where
you
configure
components
and
link
them
together
via
expressions
and
the
there's
quite
a
few
reasons,
we're
looking
at
implement
our
own
language.
There
is
a
rfc
on
river
that
I
will
link
in
the
document
that
connects
to
it
and
goes
over
some
of
the
concepts
and
we
are
drip
feeding
the
river
components.
That's
an
overused
term.
A
But
there
are
a
lot
of
things
that
robert
had
to
fork
and
change
to
get
river
to
use
or
get
hcl
to
do
the
things
we
want
to
do
for
flow,
so
we're
heavily
investigating
pushing
the
new
language
river.
That
does
these
things
natively
and
gives
us
a
lot
more
in
terms
of
error,
handling,
handling
of
of
go
values
and
marshalling
converting
marshall.
Might
be
the
wrong
term
back
and
forth
between
the
items
robert,
you
want
to
jump
into
anything
and
clarify.
B
Yeah,
I
I
want
to
be
really
clear
that,
like
we're
not
building
a
new
language,
because
because
we
want
to
it
really
is
like
a
last
resort
type
of
thing
where
we
tried
hcl-
and
I
really
do
like
the
syntax
of
hcl.
But
I
found
that
for
for
flow
where
it's,
where
it's
kind
of
an
expression-based
language
which
is
always
being
evaluated
at
runtime
like
over
and
over
and
over
again.
We
have
strong
performance
needs
and
also
we're
doing
a
lot
of
things
with
hcl
that
hashicorp
definitely
never
intended.
B
So
we're
relying
on
being
able
to
pass
around
like
go
interfaces
so
that
users
can
mainly
wire
together
pipelines
in
in
ways
that
you
really
wouldn't
kind
of
do
with
with
any
other
kind
of
agent.
So
those
two
things
combined
try
to
make
us
look
at
whether
or
not
it's
tenable
long
term
to
continue
using
hcl,
and
if
there
was
anything
that
we
really
wanted
in
hcl
that
you
know
we
don't
have
today
like
passing
around
functions
as
values.
You
can't
do
that
in
hcl,
so
that
led
to
river
the
rfc.
B
B
The
syntax
isn't
literally
hcl,
because
we
don't
want
to
be
confused
with
hcl.
We
want
to
make
sure
that
when
people
like
are
reading
river
code,
they
they
understand
each
river
and
they
understand
what
that
means,
but
there's
nothing
really
wrong
with
hcl
syntax
either.
So
we've
changed
just
a
little
bit
to
make
it
like
to
be
make
it
more
identifiable,
but
we're
not
trying
to
just
rewrite
all
the
syntax,
because
ucl
is
mostly
fine.
B
B
I
personally
believe
as
long
as
the
language
you
are
using
is
very
copy
and
pastable
and
users
can
tweak
things
really
easily
to
their
needs.
The
syntax
will
be
picked
up
very
quickly,
and
I
think
I
think
river
and
both
hcl
kind
of
accomplish
that
that
copy
and
paste
ability
so
we'll
see
how
it
goes.