►
From YouTube: 2021-09-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
All
right,
so,
let's
get
started.
Let
me
again,
let
me
just
share
the
notes
stock.
A
Okay,
I
think
I
I
had
a
couple
of
items.
Did
others
have
any
other
items
I
can
share
my
screen.
That's
easy.
A
Okay
good,
so
what
we
have
right
now
is
a
couple
of
items
and
I
think
just
wanted
to
give
a
quick
update.
I
think
we
chatted
about
this
last
week
also,
but
we
were
pretty
busy
with
the
you
know:
collector
core
stability
work
on
which
is
ongoing,
and
basically
that
has
included
you
know,
attending
to
the
collector
core
issues
that
we
have
had
and
been
working
with
bogdan
before
we
kind
of
pick
up
steam
on
the
prometa
prometheus
items.
That
said
again
vishwa
the
prometheus
receiver
tests.
B
I
mean
so
based
on
the
feedback
I
went
and
dug
into
the
prometheus
test.
Actually,
so
that
I
see
is
basically,
there
are
quite
a
bit
of
label
checks,
okay
for
the
test
that
we
are
missing
and
that's
what
rich
also
pointed
out,
and
so
I
have
all
of
them
listed
out.
I
will
just
close
out
the
dark
pretty
soon
and
then
we
can
start
working
on
writing
the
test,
basically
okay,
yeah
other
than
that.
B
I
don't
think
there
is
anything
different
on
the
prometheus
side
that
we
do
not
have
at
this
point.
Based
on
what
I
saw.
A
Okay,
that's
that's
great.
That's
great!
That's
really
helpful,
because
what
we
can
do
is
once
where
you're
ready,
you
know
with
the
list.
If
you
can
just
maybe
we
can
look
at
it,
should
we
again
we
can
start
working
because
you
know
one
of
our
engineers
can
help
in
kind
of
starting
to
write
some
of
the
tests
and
then
we
can
get.
You
know,
dive
deeper
and
just
keep
building
out.
The
rest
is
that
I
think,
probably
that
will
get
us
unblocked
there
and
also
get
out
so.
B
The
next
step,
the
next
step,
ideally
would
be
the
strategies
you
know.
How
are
we
going
to
automate
this?
You
know,
I
don't
know
whether
we
want
to
automate
it
for
every
merge
or
we
want
to
run
it
manually
once
in
a
while
or
I.
A
Think
you
know
again.
What
I
would
suggest
is
that
you
know
we
actually
run
it
as
a
github.
We
can
trigger
it
from
a
github
actions
workflow,
but
we
can
run
it
once
every
night
and
and
it
might
be
easier
to
do
that
initially
and
then,
of
course,
you
know
for
the
prometheus
receiver
itself.
A
B
Yeah,
and
also
what
kind
of
background
are
we
going
to
use?
How
are
we
going
to
query
the
back
end
as
a
part
of
the
automation
to
actually
validate
the
metrics,
the
values
and
then
also?
We
also
need
a
few
endpoints
that
we
need
to
scrape
that
will
have
deterministic
matrix
with
the
expected
values
and
yeah.
A
B
Yeah,
the
verification
is
basically
depending
on
the
test
case,
but
we
don't
know
where
the
data
is
going
to
be
exported
to
yeah
that
we
can
query
back.
We
can.
We
can
pull
some
automation,
but
we
need
to
make
sure
that
it's
not
very
flaky.
A
B
A
Yeah,
I
I
don't
know
how
that
would
actually
work
in
any
environment
if
somebody
were
to
take
these
tests
and
run
them
as
a
test
suite
I
mean
you'd
literally,
have
to
spin
up
a
prometheus
server
instance
and
kind
of
send
the
same
data.
If
you
will
across
the
wire
to
both
and
then
compare,
and
that
becomes
really
strange
for
anybody
to
take
and
run.
A
A
Yeah
sounds
good,
so
I
mean
again,
I
think,
in
terms
of
enablement,
let's,
let's
just
do
nightly
run
and
for
every
release
right.
B
Yeah
we
can
do
a
github
actions
yeah
for
the
nightly
events,
yeah
and.
A
C
How
about
instead
of
nightly
and
for
every
release
we
we
just,
do
it
on
merge
to
the
main
branch,
so
everything
that
gets
merged
the
main
branch
triggers
that
additional
test.
So
I
think
that
there's
really
only
the
only
difference.
The
only
different
action
point
you
guys
really
have
at
release
would
be
when
you
tag
a
release
at
which
point
it's
kind
of
too
late
to
be
running
these
tests.
I.
D
B
A
C
A
B
We
can,
we
can
start
with
after
merge
for
a
vpr
and
then
see
how
it
goes
and
then.
C
Doing
it
that
way,
it
doesn't
block
anything
right.
So
if
there
are
three
pr's
that
are
going
to
be
merged
in
quick
sequence,
all
three
of
them
can
be
merged,
and
you
know
the
first
two
will
end
up
being
canceled
and
that
the
third
one
will
run.
So
I
I
I
think
it's
post
hoc,
it's
non-blocking,
it's
probably
the
the
best
place.
We
have
right
now,
if
we're
not
going
to
put
it
in
the
pr
path.
A
What
is
that
anthony?
What
did
what
does
that
mean?
So
if
you
have
three
pr's
that
got
merged
into
the
receiver
for
the
receiver,
you
know,
then,
when
does
the
test
get
triggered
on
every
merge,
or
what
did
you
do.
C
It'll
get
triggered
on
every
merge.
I
think
what
will
happen
if,
like
when
the
second
pr
gets
merged.
If
the
first
one
is
still
running,
the
first
one
will
get
cancelled
and
the
new
one
will
get
kicked
off
at
the
second
and
the
same
thing
with.
A
A
Yeah
yeah
exactly
because
then
we
at
least
again
the
objective
and
should
be
that
let's
get
the
tests
so
that
yeah
they
exist
right.
So
let's
target
that
and
we'll
just
trigger
it.
A
So
should
we
look
at
the
dock
and
see
if
there's
anything,
did
you
want
to
add
anything
else
here.
B
No,
they
are
all
very
specific
something.
A
B
You
know
the
upf
labels.
There
are
quite
a
bit
of
label
test
that
prometheus,
actually
checks
for
so
I
will.
I
will
basically
classify
them
as
a
label.
You
know
checkers
and
then
I'll
just
put
all
this
or
all
the
test
cases
yeah.
That's
all
we
need.
A
All
right
cool,
because
then
you
know
we
can
just
so.
The
action
item
is
that
vishwa
will
add
and
add
our
naval
test
test
requirements
into
from
prometheus
into
doc,
and
then
we
can
implement
next
week
right
starting
next
week.
B
So
one
other
question
not
related
to
this,
I
have
is,
do
we
know
when
we
are
actually
shooting
announcing.
The
metrics
is
stable
and
then
moving
the
receiver
to
back
to
the
collector
repository
from
the
complete
repository.
A
So,
based
on
so
now
that
you
know
tracing,
there
is
at
least
a
you
know,
milestone
that
has
been
achieved
for
tracing
core
stability.
A
Configuration
work
is
in
progress,
for
you
know
overall
collector
right,
but
that
said
we
we
should
talk
about
the
metrics
items
on
the
collector,
because
we
have
a
pretty
good
backlog
and
understanding
of
what
needs
to
be
done
and
we
were
targeting
about
initially,
as
we
had.
You
know,
kind
of
discussed
this.
It
was
going
to
be
november,
so
you
know
if
we,
if
we
take
all
of
october
and
november,
I
think
it
is
about
eight
weeks
worth
of
you
know
targeted
effort.
A
You
know
with
multiple
engineers,
but
we
do
need
to.
We
have
some
large
items
for
metric
stability
that
need
to
be
completed
on
the
on
the
collector
so
and
then
there
is
the,
and
these
are
also
related
to
the
prometheus
receiver
itself
right.
So
I
I
would
say
that
november
is
a
safe
target.
At
this
point.
A
B
Okay
and
the
otf
also
needs
to
be,
we
haven't
taken
a
dependency.
A
Yes,
but
but
we
will
right,
we
are
right
now
tlp10.
A
There
is
a
pr
that
I
think
alex
filed
already,
which
is
you
know,
to
migrate
to
otl
p10,
but
there
are
some
breaking
changes
right,
so
so
we'll
have
to
accommodate
that
then
there's
another
major
major
part
where
we
had
discussed
rewriting
the
collector
metrics
processor
so
that
it
can
be,
you
know
again,
be
coupled
and
generic
enough
to
be
able
to
be
used
by
developers
who
are
building
other
components
for
the
collector,
as
well
as
obviously
having
external
end
user
configuration
stability
right.
A
So
there
was
that
discussion
and
there's
a
design
that
we
have
reviewed,
which
we
had
proposed,
but
we
haven't
finalized
that
yet
so
the
idea
is
right.
Now
that
the
you
know
there.
A
We
need
to
finalize
this
so
that
three
big
items
of
prometheus
receiver
stability,
then
so
that
addresses
service
discovery,
also
because
the
collector
in
general
wants
to
use
the
general
service
discovery
mechanism.
That's
in
the
go,
sdk
and
anthony
correct
me.
If
I'm
not
if
I'm
wrong,
that
work
hasn't
started
yet
right.
A
Correct
and
and
and
so
that's
the
service
discovery
stability,
then
there's
the
prometheus
receiver,
which
we
will
keep
for
prometheus
service
discovery
and
then
metrics
processor
that
needs
to
be
built
out
and
the
configuration
work
so
there's
a
fair
bit
of
work.
That
is
actually
going
to
be
done
in
the
next
couple
of
months,
so
I
don't
envision
anything
to
land
before
november.
A
G
Okay,
cool,
I
thought
about
your
question
for
the
last
two
weeks
and
didn't
come
up
with
very
much
at
all.
I
realized
that
my
experience
on
this
sidecar
has
a
lot
to
do
with
detecting
resets
that
are
out
of
our
control
when
you're
in
the
prometheus
environment,
like
I'm
just
seeing
prw
come
through
essentially,
and
there
were
some
rules
that
we
wrote
down
for
that
about
start
time,
handling
and
resets
and
so
on,
but
I
don't
think
they
come
into
play
for
this
type
of
testing
you're
talking
about.
A
A
I
see
okay
because
I
mean
josh.
We
were
just
discussing
that
that
it's
pretty
hard
for
or
it's
it's
very
complex,
to
build
a
you
know,
kind
of
and
a
pipeline
that
you
know
runs
in
parallel
for
our
tests
for
our
receiver
tests
and
then
also
compares
it
with
the
prometheus
server
on
all
these
tests.
And
then
you
know,
compares
the
results
right,
so
we're
trying
to
figure
out.
You
know
if
we
can
just
trigger
it
on
every
merge.
That's
what
we
were
discussing.
A
G
That
sounds
okay.
I.
G
G
But
it
would
be
like
validating
a
federation
of
permanent
servers,
which
I'm
sure
is
not
easy.
But.
G
A
Yeah
agreed
and
yeah
agreed
absolutely
because
I
think
that
you
know,
as
long
as
we
can
validate
the
conditions
that
we
are.
You
know
from
the
tests
we
itemize,
whether
that's
label,
verification
or
others.
It's
probably
good
enough
metric
types,
mostly
label
tests
right.
A
Okay,
so
let's
we
have
a
plan
for
that
which,
how
do
you
guys
have
any
bandwidth
to
work
on
some
of
the
prometheus
related
metrics
work
in
the.
A
B
We
have
only
like
sorry
me
and
grace
okay,
and
we
probably
spend
like
five
to
ten
percent
of
our
time
here.
B
Yeah
yeah,
we,
we
will
certainly
pick
up
a
few
things
and
help
out
here,
but
I
don't
think
we'll
be
able
to
do
major
things
unless
we
put
more
people
here,
which
I
don't
think
will
happen
this
year.
A
Okay,
I
mean
the
reason
I
ask
is
because
I
think
that
even
your
work,
you
know
your
help
on
reviewing
as
well,
as
you
know,
just
participating
in
the
design
discussions,
and
you
know
maybe
testing
and
verifying.
That
would
be
super
helpful.
Because
again,
I
think
you
know,
let's
plan
out
the
components
that
we
are
looking
at
and
we
can
walk
through
them
because
we
have
been
starting
to
look
at
them
like
what
are
all
the
items
that
really
need
to
be
done
for
the
prometheus
receiver.
What
are.
E
A
Items
that
need
to
be,
you
know,
completed
for
the
remote
right
exporter,
as
well
as
the
as
well
as
the
drop
in.
A
The
pull
exporter
on
the
collector
and
then
and
and
all
the
related
tests
right,
those
are
the
at
least
at
the
component
level.
That's
the
idea,
and
then
there
are
overall
collector-based.
You
know,
functions
functionality,
which
is
like
the
metrics
processor.
A
How
do
you
actually
handle
processing
for
different
types
of
aggregations
or
different
types
of
data
for
different
backends
right
and
that's
a
more
generic
collector
problem,
but,
on
the
other
hand,
also
affects
the
way
that
we
are,
you
know,
aggregating,
otlp,
metrics
and
then
into
what
prometheus
can
consume,
or
vice
versa
right,
which
is
being
sent
out
to
different
backends.
So
there's
a
fair
bit
of
work.
I
think
that
is
kind
of
fragmented
right
now
on
the
collector
and
that's
an
area
I
think
which
will
take
some
effort,
but
it's
all
still.
A
B
Okay,
we
can,
we
can
definitely
help
out
if
you
have
anything
specific
items
that
you
want
to.
You
want
to
help
reach
out
to
us.
A
A
Yeah
yeah,
absolutely
because
I
mean
again
everybody's
review.
Really
it's
super
valuable.
So
that's
why?
For
these
components,
especially
so,
let's
we'll
take
an
action
item,
maybe
anthony
you
and
I
can
review
the
what
we
have
right
now
on
our
backlog
and
then
kind
of
report
back
to
the
group
next
week.
Yeah.
Thank
you.
Okay
sounds
good
josh.
Is
there
anything
else
on
your
end,
which
you
want
to
bring
up.
A
Okay,
no
worries;
no,
no.
I
mean
I'm
just
asking
because
we're
just
trying
to
make
sure
we
have
a
comprehensive
backlog
for
the
remaining
items
that
are
to
be
done.
B
One
more
thing
that
came
up
in
our
discussion
within
our
group
last
week
was
there
is
work
going
on
to
get
the
prometheus
agent
right.
The
grafana.
B
So
do
we
know
how
that
would
actually
impact
the
the
prometheus
receiver,
because
when
that
happens,
I
think
that's
going
to
be
pretty
compliant
with
prometheus
from
day
one.
That's
what
I've
been
seeing
from
the
pr's
that
are
going
in
so
it
will
be,
it
will
be.
It
will
be
a
very
similar
thing
to
receiver
in
the
open
telemetry
pipeline.
Of
course,
there
are
rather
benefits
here
because.
A
B
No,
no!
No,
so
they
are
basically
saying
very
similar
to
the
premier's
receiver
component
that
we
have
in
the
connector.
The
the
agent
will
be
the
same
thing.
For
example,
you
won't
have
remote
right,
you
won't
have
recording
rules,
it
will
just
act
as
an
agent
data
collection,
agent.
B
And
that's
all
that's
already
actually
there
and
they
are
just
defective.
Yes,
you
know
to
get
those
pieces
up
and
running
by
the
end
of
this
year,
I'm
assuming
based
on
the
pr
feedback
that
I
see
so
when
that
comes,
I
think
that
will
be
an
interesting
comparison.
You
know
between
doing
this
otlp
conversions,
rather
than
taking
the
data
directly
from
the
agent
and
exporting
it.
A
That's
yeah,
that's
a
fair
point
and-
and
I
mean
again,
I
don't
think
at
right
now
we
are
looking
at
you
know
looking
at
replacing
the
prometheus
receiver,
because
at
the
end
of
the
day
you
know
the
prometheus
receiver
has,
you
know,
been
used
and
built
for
the
use
cases
that
you
know
the
collector's
handling
today,
but
we
should
definitely,
I
would
say
we
should
take
a
look
at
you
know
what
changes
are
being
made
there
and
can
anything
be
reused.
I
don't
see
it
being
a
drop-in
replacement.
A
A
A
Because
josh,
I
think
we
should
take
a
look
at
that
anthony
so
that
you
know
we
make
sure
that
that's
something.
A
Is
it
an
sorry,
I
haven't
been
tracking
the
gca
code,
but
I
can
go
and
look
up.
A
F
B
They
even
are
saying
the
expression
browser
will
also
be
posted
on
the
agent.
A
A
B
So
rich
might
be
able
to
give
some
updates
next
time
you
can.
Probably
this
is
supposed
to
be
coming
by
this
december.
A
A
Okay,
cool,
I
think
that's
all
we
had.
Let's,
we
have
several
action
items,
so
we
shall
come
back.
Let's
come
back
with
us
and
get
started
all
right.
Thank
you.
Thank
you.
Thanks.
Everyone
bye.