►
From YouTube: 2021-11-24 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
A
And
password
which
allows
us
to
to
get
by
with
only
using
one
zoom
account,
whereas
before
we
had
four,
we
had
each
each
account
had
a
single
meeting,
so
we
had
to
try
to
avoid
overlapping
meetings
on
the
same
account,
this
will
save
us.
Ideally,
it
will
save
us
some
money,
but
a
little
more
cognitive
overhead,
because
you
have
to
actually
keep
track
of
which
meeting
is
where.
A
They'll
need
the
password
to.
Let
me
let
me
find
the
link
to
the
calendar
and
just
put
that
in
there.
A
B
Yeah
understood,
but
it's
it's
quicker
if
we
just
give
them
direct
links.
D
E
Yeah
the
link
was
actually
like
it's
a
404,
but
then
I
just
took
the
end
number
and
put
it
in
as
journey,
and
then
that
worked.
B
B
A
I
just
joined
the
link
that
I
had
for
the
other
columnist.
I
have
an
old
old
link,
somehow
which
I
I
don't
think
I
did.
F
Yeah
I'll,
let
them
know
I
will
join
you
here.
B
B
Yeah
we
can,
we
can
potentially
adhere
or
ask
cncf
steph
to
add
here
in
the
wg
prometheus
channel,
and
that's
probably
for
like
that,
won't
happen
immediately.
A
That
is
different
from
the
link
I
had.
I
had
been
using
the
link
in
the
doc,
though,
which
is
now
gone,
so
I
guess
the
link
that
I
had
on
my
calendar
was
outdated
even
recently,
so
apparently
there's.
A
B
Yeah:
okay,
let's:
let's
move
over
to
the
other
and
and
see
if
it
works
and
then
figure
out
the
rest
for
next
time.
A
I
I
think
we
should
stay
here
if
you
want
to
go
over
there
and
ask
them
to
welcome
here
and
provide
them
a
direct
link.
That's
fine,
but
here
let
me
put
the
direct
link.
F
Yeah
I
was
there
and
let
them
know
about
other
requests
to
join
there,
not
here
only
for
today
and
I'm
sure
you're
updating
the
meeting
notes
to
meet
with
this
new
week.
So
please
join
the
other
meeting.
The
previous
you
used,
the
previous
germans.
A
G
I
was
just
asking
regarding,
like
varied
use
cases
for
infinite
values,
so,
as
I
understand
like,
the
histogram,
buckets
could
also
have
infinite
values
and,
apart
from
untyped
and
gorge,.
H
So
the
answer
is
that
in
openmetrics
you're,
basically
talking
gauge
unknown
and
summary
quantiles
in
prometus
text
format,
they
shouldn't
be,
but
it
could
be
anywhere.
G
Yeah
and
the
so
during
this
test,
the
bugs
that
were
discovered
were
regarding
the
incorrect
start
time
stamp.
So
so
these
particular
issue
checks
are
commented
out
with
a
to-do
remark
in
the
in
the
tests.
So
one
is
the
incorrect
start
time
stamp
during
the.
G
Oc
2,
dlp
transformation
and
indirect
histogram
and
summary
count.
Value
and
other
thing
is
incorrect,
honest
time
on
a
time
stamp
for
counter
matrix
and
then
we
have
the
and
we
need
to
buffer
and
sort
the
the
mat.
The
data
points
in
metric
builder
before
we
build
the
metrics,
so
these
issues
are
filed
on
the
open
on
the
collector
contract
wrapper
on
the
open,
telemetry.
A
G
C
Okay,
so
again
can
we
go
through
the
pr's
that
are
open,
because
I
think
david
and
vishwa
we'd
definitely
ask
for
your
reviews,
because
otherwise
you
know
these
tests
won't
get
merged.
I
think
anthony
has
already
reviewed
most
of
them,
but
anthony
you're,
the
other
approver,
so
david.
I
think
we
need
your
review
also.
A
Yes,
I
I
think
there
are
a
number
of
them
that
are
still
in
the
open
hollyoak
for.
A
I
that
I
haven't
looked
at,
I
need
to
get
to
those
today.
C
A
A
C
A
Let
me
see
if
I
can
share
this
screen
the
screen
yeah.
So
this
is
a
pr.
It
started
a
while
back
by
a
manual,
but
it
finishes
adding
the
otl
the
direct
to
otlp
data
pipeline
for
metrics
coming
out
of
the
prometheus
receiver.
A
Which
implements
the
the
appender
interface,
so
we
have
appends.
We
don't
currently
handle
exemplars,
although
I
think
we
can
at
this
point,
because
I
believe
p
data
has
support
for
exemplars
now,
but
we
can
add
that
at
a
later
date,
so
we've
got
append
and
commit
has
a
metrics
builder
for
otlp
and
the
adjusters
and
so
all
of
the
pipeline,
and
then
it
also
sets
up
the
the
the
appender
provider
interface,
that's
used
by
the
storage
manager,
such
that
when
it
asks
for
an
appender.
A
A
We're
going
to
start
it
off
with
a
value
of
false
so
that
the
the
open
census
implementation
will
be
used
by
default.
Initially,
at
some
point
in
the
future,
we'll
flip
that
so
that
the
direct
p
data
implementation
will
be
used
and
then
eventually
we'll
remove
this
and
remove
the
open
census
implementation
entirely,
leaving
just
the
direct
from
prometheus
to
p
data
conversions.
A
If
anyone
wants
to
take
a
look
at
it,
it's
it's
a
bit
large
about
3000
lines
added,
I'm
not
sure
that
there's
much
that
could
be
taken
away
from
this
and
make
it
still
a
wholly
useful
thing,
though
like
even
if
we
tried
to
to
not
include
the
feature
gate
and
not
enable
the
pda
to
direct
pipeline.
That
would
just
follow
up
in
a
second
pr,
because
the
the
functionality
wouldn't
be
useful
without
this
and
that's
basically
a
high
level
overview
of
that.
A
Is
there
any
questions
there?
I
might.
I
don't
think
this
did
much
in
the
way
of
changing
the
the
tests
other
than
set
up
some
of
the
end-to-end
tests.
This
one!
Sorry,
no!
That's
in
helper,
I
believe
yeah.
So
it
sets
the
the
helper
functions
that
that
are
used
for
the
end-to-end
tests
to
run
through
both
the
open
census
and
p
data
pipelines.
A
C
Are
there
anthony
what
are
the
implications
for
the
open
census
dependencies?
They're?
No
longer
I
mean
obviously
with
this
change.
The
tests
will
no
longer
be
dependent
on.
A
They
are
they're
still
so
the
the
open
senses
implementation
is
still
there.
It's
still
the
default
implementation.
That's
that's
used
until
we
remove
the
feature
gate
entirely
and
remove
the
open
census
implementation.
There
will
still
be
a
dependency
yeah.
A
I
I'm
slightly
perplexed
as
to
how
the
the
gosum
file
is
370
lines
shorter,
but
maybe
it
just
hasn't
been
cleaned
up
in
a
while.
We
haven't
actually
removed
much
much
dependency,
so
so
yeah,
it's
it's
not
going
to
get
smaller
just
yet.
Only
after
we've
gone
through
the
the
feature
gate
process
of
you
know.
C
C
Any
questions
david:
do
you
see
any
issues.
I
A
Yeah
it's.
The
implementation
is
fairly
straightforward.
If
you're
familiar
with
how
the
existing
implementation
works,
all
the
same
pieces
and
moving
parts,
are
there
just
going
directly
to
p
data
instead
of
through
open
senses,.
C
Yep,
are
you
seeing
any
performance
improvements
in
running
the
tests
anthony
I
mean,
I
guess
I'm
just
assuming
you
haven't
just
gotten
to
that
point.
Yet
right.
A
Yes,
I
don't
know
that
there
are
really
any
benchmarks
around
this
part
of
the
process.
The
tests
take
a
little
less
than
twice
as
long
to
run.
So
maybe
it's
slightly
faster.
C
That's
any
improvements
are
good,
I
mean
again
just
for
context.
You
know
we
have
a
whole
battery
of
tests
that
we
run
downstream
and
and
it's
just,
we
constantly
see
timeouts
on
on
a
lot
of
these.
You
know
test,
workflows,
yeah,
that's
the.
C
Wow
doubled.
C
All
right
cool
so
anthony,
thank
you.
I
know
vishwa
did
you
have
any
updates
or
grace
or
rashmi.
C
Grace
I
just
wanted
to
follow
up
on
the
you
know,
one
of
the
issues
you
had
filed
on
the
prometheus
project
about
the
ui
driven
implementation
that
you
you
had
talked
about.
Any
updates
on
that.
E
Yes,
not
right
now,
I
haven't
had
time
to
get
to
it.
C
Okay,
good
good,
I
mean
again,
you
know
one
of
the
objectives
of
all
this
work
has
been
to
make
sure
that
we
can
maintain
compatibility
closely
with
the
prometheus.
You
know
core
and-
and
I
think
that
we
are
as
we
you
know,
move
towards
metrics
stability.
C
Again,
it
would
be
great
david
if
you
have
any
requirements,
you
know
which
are
not
covered
yet,
because
I
think
one
of
the
open
items
was
the
wall
implementation,
and
I
know
that
you
had
filed
a
pr.
You
know
for
the
general
wall
implementation
that
was,
I
think,
reviewed
and
merged,
but
there
was
also
prometheus
specific
wall
implementation
set
of
pr's,
which
are
kind
of
in
in
in
an
in
in
an
intermediate
state.
So
I
was
just
curious
as
to
you
know
what
what
the
final
resolution
there
was.
C
I
just
the
reason
I
point
to
this
is
because
we
created
a,
I
created,
a
task
board
anthony,
and
I
were
looking
at
this
and
again
just
for
everyone
to
have
context.
This
is
the
test
board.
We
are
looking
at
the
open,
telemetry
project,
and
this
was
the
number
two
which
is
the
support
wall
capabilities.
C
Similar
to
prometheus
server,
that
was
so
anthony,
is
obviously
working
on
one
number
one,
but
just
wanted
to
make
sure
that
if
there
were
any
missing
items
there,
you
know
or
the
context
for
the
specific
wall
implementation
at
this
point
should
we
just?
Is
it
needed
anymore
or.
I
A
I
think
it's
very
similar
to
where
we're
at
with
the
the
p
data
conversion
in
the
receiver
is
that
there's
an
implementation,
that's
not
fully
wired
up
yet
in.
C
C
So
anthony,
are
you
saying
this
particular
pr
this
one?
The
prs
for
this
issue
were
the
implementation.
That's
supposed
to
be
wired
up,
one
that
emmanuel
worked
on.
I
There
is
a
glue
and
use
right
ahead.
Log
pr.
I
I
wasn't
actually
aware
of
this,
but
it
looks
like
it'll
probably
need
to
be
revived.
C
A
Possibly
this
one
maybe
doesn't
need
a
feature
gate
because
there's
a
config
option
or
do
you
wish
to
enable
it,
and
I
I
think
that
that
should
be
a
long-lived
option.
Anyways
yeah.
I
A
A
C
I
I
don't
necessarily
have
a
stake
in
in
this,
since
google
doesn't
use
the
prometheus
remote
right
very
much.
Of
course,
I'm
happy
to
to
help
where
I
can.
I
think
it
might
be
useful
for
someone
to
try
the
generic
write
ahead.
Vlog-Esque
processor
or
no,
no,
it's
a
it's
part
of
the
retry
queue
in
export
is
actually
right.
I
I
Yeah,
we
don't
use
it
in
the
google
exporters
either.
For
that
reason,
so
maybe
I
should
look
into
fixing
that,
but
in
the
meantime
I
think,
if
that's
the
case,
this
is
a
fine,
short-term
or
potentially
long-term
solution
for
the
remote
rate
exporter
and
I'm
happy
to
help
review.
C
Yeah
no
worries
I
mean
david.
If
you
can
take
a
help
us
review,
then
we
can
definitely.
You
know
at
least
bringing
bring
this
to
a
conclusion,
and
that
would
be
very,
very
useful
because
I
mean
it
is
needed
for
at
least
the
remote
right
pipeline.
C
Yeah
but
I
mean
I
think,
anthony
we
can
discuss
this,
but
I
think
one
of
one
of
us
can
pick
it
up.
Okay,.
A
Yeah
I
mean
I
could
probably
pick
this
up
after
I
finish,
shepherding
the
the
other
pr
for
the
receiver.
C
Yeah,
okay,
cool
I've
just
made
a
note
on
that
pr,
also
so
that
so
that
it
on
that
issue.
Sorry,
no,
so
that
we
can
track
it
or
for.
C
Okay,
but
I
think
that
in
terms
of
going
back
to
the
list
of
issues
that
we
had,
I
think
the
remote
right
receiver
tests-
we
are
right
now
working
on
remote,
right
exporter,
we're
just
verifying
the
stability
of
the
remote
right
exporter
right
now,
the
wall,
pr
we
just
discussed,
and
then
there
is
the
parity
for
the
prometheus
receiver
with
prometheus
server,
and
this
is
something
again
which
is
a
larger.
You
know,
we've
had
this
discussion
in
iterations
as
to
what
is
considered
to
be
a
drop
in
replacement.
C
If
at
all-
and
you
know
again,
david-
are
there
specific
requirements
that
you
need
from
this
pipeline,
which
need
to
be
supported
and
aren't
already?
Are
there
other
improvements
that
need
to
be
made
for
the
pull
exporter?
If
that's
something
you
guys
are
using
again
just
kind
of
understanding,
some
of
the
other
use
cases.
I
Yeah,
I
don't
think,
there's
anything
big,
that's
missing.
We
are
missing
the
the
data
types.
I
think
that's
already
on
there
yeah.
C
I
Not
necessarily
from
google's
use
cases,
it's
not
necessarily
a
blocker,
and
that
is
a
if
I
remember
correctly
would
require
open
telemetry
data
types
to
fully
support,
anthony,
correct
me,
fund.
A
Yeah,
I
yeah,
I
think
that's
that's
correct
as
well
like
the
gauge
histogram
is
something
that's
been
discussed
in
the
metrics
seg
for
a
while,
and
they
haven't
really
come
to
a
good
way
to
support
it.
Yet
so,
but.
I
Or
even
like
state
sets
and
info,
I'm
not
sure
how
we're
going
to
do
the
if
we
want
it
to
come
out
prometheus
remote
right
as
a
state
set
or
as
an
info.
I'm
not
sure
how.
Today
we
would
be
able
to
propagate
that.
I
But
yeah
there's
nothing.
I
know
of
the
biggest
thing
from
my
perspective
is
that
the
configuration
is
compatible
and
I
think,
we're
basically
there.
We
don't
support
like
verbatim
configurations,
which
I
think
is
more
of
a
usability
issue
than
a
compliance
issue,
or
at
least
that's
how
I
see
it.
C
Are
there's
anything?
Is
there
anything
else
on
the
configuration
side,
vishwa
or
david?
That
again,
you
know
we'd
like
to
better
understand,
because,
as
we
put
in
these
feature,
gate
implementations
also
on
the
collector
is:
are
there
any
specific,
you
know
use
cases
I
mean
we
have
seen
a
few
where
the
future
gates
obviously
handle
those
use
cases,
but
regarding
configuration
definition
of
specific
metrics,
you
know
or
just
other
options
that
are
needed
and
the
configurations
to
be
passed.
Are
there
any?
Is
there
any
any
gap
in
the
configurations
today.
C
C
J
Yes,
yeah
and
then
the
the
renaming
the
few
functionality-wise
a
few
things
doesn't
work
now
the
metric
renaming,
as
well
as
the
job
and
the
instance
re-labeling.
There
are
a
few
things
that
that
makes
this.
You
know
not
100
compatible
right
away,
but
I
think
they
are
all
workable,
not
a
blocker,
maybe.
C
Yeah,
but
I
mean,
are
there
any
again?
What
my
request
really
is
is
that
if
you
find
any
gaps
in
terms
of
configurations
that
you're
not
being
able
to
handle,
please
itemize
this,
because
at
some
point
you
know
at
the
end
of
the
day
the
really
the
goal
is,
you
know
how
seamless
is
the
experience
to
the
user
and
and
again
configuration
is
one
of
those
areas
where
you
know.
C
C
Yeah,
at
least
you
know
so
that
the
configurations
that
are
you
know
fully
consumable
by
the
collector
for
prometheus.
J
C
C
C
C
The
collector
is
looking
at
you
know,
building
a
generic
pipeline
if
and
and
that's
something
that
the
design
is
being
discussed
for
so
then
we
have
to
see
how
does
the
prometheus?
C
How
do
the
prometheus
cases
fit
in?
Do
we
actually
run
that
in
parallel
and
then
can
just
be
invoked
by
the
you
know,
general
service
discovery
model,
as
well
as
the
general
receiver,
if
you
will
or
otherwise
right
so
there's
there's
again,
we
need
to
kind
of
we'll
work
on
that.
C
You
know
with
on
the
collector's
side
with,
but
to
ensure
that
there
is
collect.
You
know
full
compatibility
for
the
prometheus
pipeline
in
that
okay
make
sense.
C
The
other
area
that
I
again
this
is
an
additional
area
that
we've
been
just
you
know
looking
at
because
as
given
you
know,
we've
gone
through
the
rigor
of
testing
with
the
open
metrics.
You
know
test
suite
and
really
looking
at
the
prometheus
receiver
and
exporter
test
tests
in
more
detail.
C
One
of
the
things
I've
seen
is
that
there's
no
standardization
on
the
sample
apps
that
are
used
for
you,
know,
testing,
and-
and
this
is
again
you
know
any
engineer
who
is
building
any
features
for
any
kind
of
prometheus
compatibility
would
usually
use
this
one
right.
That
includes
a
data
generator
that
also
includes
generating
application
level
metrics.
You
know
at
least
simulating
them
and
then
also
intro
metrics.
So
is
there?
Maybe
I
mean
if
if
you
are
using
specific
apps
or
have
built
them
are
those
available?
C
Can
we
collate
them,
because
we
have
built
a
couple
and
I
don't
think
any
of
them
are
complete
per
se,
even
the
ones
you
know
we
have
used
the
ones
that
frederick
has
available
upstream
on
premiere
prometheus,
but
at
least
that's
a
gap
that
we
found.
C
I
We've
had
similar
struggles
and
I
was
yeah,
I'm
hoping
to
spend
part
of
december
playing
around
with
a
bunch
of
different
applications.
I
do
know
that
especially
ones
right
now
that
send
untyped
metrics
yeah
or
maybe
I
know
that
was
fixed.
I
think,
but
we
just
haven't
updated
to
the
version
that
fixed
it.
But
that's
our
big
problem
right
now,
but
I
think
that
might
be
a
nice
problem.
C
Is
there,
is
there
a
specific
app
that
you've
written
or
are
using?
You
know,
out
of
the
plethora
of
apps
floating
around.
I
C
Are
you
going
to
open
source
it,
because
that
might
be
something
useful
that
you
know
we
can
all
build
upon?
We
also
have
two
specific
apps
that
we've
been
using,
but
just
just
from
a
testing
standpoint
right.
I
think
that
it
would
be
useful
to
at
least
have
one
baseline
that
works
or
people
can
use
again
grace
or
vegeta.
I'd
like
to
also
better
understand.
J
C
J
There
for
basic
end-to-end:
no,
you
know.
J
When
we
take
a
new
drop
of
the
receiver,
just
just
to
make
sure
that
you
know
all
the
types
are
flowing
and
everything
looks
good,
yeah
it'll
be
great.
If
one
of
us
can
take
that
app
and
then
you
know
put
it
out.
C
Because
one
of
the
things
we
could
do
right
in
the
next
few
weeks
is
that
if,
if
we
all
decide
that
you
know
this
is
a
good
app
to
use,
then
we
can
actually,
you
know,
identify
what
what
the
gaps
are
and
maintain
it
on
hotel
right,
so
that
that's
something
that
is
available
for
anyone
who
is
testing
a
prometheus
workflow
can
take
and
run
with.
C
And
we
we
use
that
too
for
testing,
but
that's
good
for
basic
testing.
There
are
a
lot
of
use
cases
that
are
missing
so
again.
You
know
we
have
another
app
that
we
have
which
is
being
used
by
us
I'll
just
share
that.
J
G
I
C
C
Okay,
because
I
mean
we
have
been
building
out,
you
know
like
the
sample
app,
which
I
just
shared
on
the
as
a
link,
and
then
there
is
another
one
which
is
actually
a
version
of
this,
but
we
will
you
know
again.
It's
a
good
good
thing:
we'd
like
to
kind
of
push
this
to
at
least
the
hotel
reapers,
so
that
that
could
be
used.
I
Yeah
it'd
be
cool
to
include
some
open
metrics
on
an
endpoint
as
well.
C
Yeah
because
then
at
least
you
know
people
can
use
a
specific.
This
is
the
other
sample
app
that
we
have.
I
think
these
are
similar
purush
again,
I
don't
know
if
you
looked
at
these,
don't
know
which
one
you
guys
are
using,
or
did
you
write
your
own
right
now.
G
C
C
We'll
we,
what
we'll
do
is,
at
least
on
our
end.
We
will
make
sure
this
is
updated
for
all
the
tests
that
have
been.
You
know,
reflect
on
the
open,
metrics
side.
Also,
and
all
the
you
know,
tests
that
which
will
be
outlined
for
testing
the
receiver
and
make
sure
that
you
know
that
all
those
use
cases
are
supported
on
this
sample
app.
C
I
C
A
C
Everybody
usually
tends
to
go
and
pick
that
up,
but
again
I
think
we
found
there
were
some
gaps
in
that
in
the
implementation,
especially
for
you
know,
if
you're
doing
detailed
testing
on
different
specific
nands
or
you
know
up
network
and
others
specific
items,
all
right
cool,
any
other
items
that
you
guys
wanted
to
discuss.