►
From YouTube: 2022-01-27 Governance Committee private 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
B
C
I
can't
win.
I
can't
win
something
about
like
this
desire
to
when
you're
changing
a
meeting,
invite
just
to
change
the
meeting
invite,
but
that
if
you
don't
create
a
brand
new
one
or
maybe,
if
you
do,
then
google
like
automatically
create
a
meeting
note
stock,
which
is
like
a
feature
of
google
calendar.
But
it's
not
our
doc
or
something
does
that
make
sense.
D
Yeah,
I
think
someone
mentioned
in
another
setting
that
you
can
just
add
a
I
don't
know
and
then
I'll
complete
the
meeting
and
then
that
file
would
then
be
attached
to
the
invitation
as
the
meeting
notes.
So
you
can,
you
can
do
the
other
way
around.
E
C
The
meeting
notes
that
I
clicked
on
were
correct.
Oh
I
see
there's
two
all
right,
whatever
I'll
try
to
maybe
I'll
be
able
to
fix
this.
B
D
C
C
She
would
be
kind
of
great
if
alito
was
here
for
this,
because
I
think
she'll
actually
know
the
answer,
but
others
here
might
also
have
insight
into
it.
I
was
talking
with
a
customer.
B
C
I'll
bring
it
up
anyways
I'm
curious
to
see
if
anyone
has
any
insight
into
this,
so
I
was
talking
to
the
customer
yesterday,
not
really
about
landsat,
but
about
open,
telemetry
stuff
and
they
they
were
very
knowledgeable
from
ethios
ecosystem.
Because
of
you
know,
I
don't
know
whatever
just
their
career
history
and
their
impression,
which
I
may
not
be
accurate
at
all,
but
their
impression
was
that
you
know
they
were
polite
about
this.
C
But
if
I
was
less
polite,
they
were
saying
like
from
a
prometheus
community
standpoint,
open
telemetry
seemed
like
it
came
in
with
like
a
separate
and
technically
reasonable,
but
relatively
incompatible
way
of
doing
things
that
there
have
been
like
efforts
to
emerge.
These
two
things
you
know
going
back
over
a
year
at
this
point,
which.
C
Somewhat
working,
but
but
that
when
you
come
down
to
it
like
the
the
you,
you
can't
get
prometheus
either
the
actual
piece
of
software
or
many
of
the
protocols
to
play
nice
open
telemetry
today
and
it
doesn't
seem
like
that's,
really
a
priority
and
that's
somewhat
at
odds
with
my
understanding
of
things,
at
least
from
these
meetings,
where
we
hear
a
lot
about
meteos
compatibility
and
work
with
openmetrics
and
so
on
and
so
forth.
C
So
I
think
my
question
was
like
what
you
know
if
you're
running
prometheus
right
now
and
you
wanted
to
use
open,
telemetry,
collector
or
open
telemetry
protocols,
and
things
like
that
like
how
far
away
from
that
working
at
like
a
literal
level
and
then
working
in
like
a
practical,
scalable
level.
C
Today
and
then
I
had
opportunity
to
totally
randomly
talk
to
michael
thousand
this
morning
from
aws
totally
coincidental
conversation
and
his
take
was
that
it
actually
works
pretty
well
and
the
hotel
collector,
or
at
least
the
adot
collector,
that
she's
more
familiar
with,
can
like
take
a
prometheus
configuration
file
and
just
come
up
and
running,
pull
in
the
data,
getting
it
into
hotel
and
then
exporting
it
via
normal
exporters.
So
I'm
just
curious
like.
B
That's
my
impression
as
well
is
that
for
sort
of
basic
use
cases
with
the
collector
it
works
fairly.
Well,
there's
there's
no
major
blockers
there.
I
would
not
be
shocked
if
there
were
issues
where
you're
like
trying
to
translate
twice
or
something
like
prometheus
into
hotel
out
to
prometheus.
If
there
were
some
problems,
but
I'm
not
the
right
person
to
speak
to
this
with
authority.
D
Sorry
go
ahead,
trustee
yeah,
so
soon
on
the
collector's
side
of
things
we
do
yeah,
so
basic
use
cases
they
do
work,
but
we
are
missing
things
that
are
more
complex.
I've.
We
have
quite
a
few
book
or
open
above
issues
of
bug.
Reports
on
the
collector
and
we've
stayed
quite
a
long
time
without
people
acting
on
them.
D
D
D
Now
there
are
things
missing,
like
exemplar
support
are
missing.
I
think
I've
seen
apr
recently
about
that.
So
we
don't
have
a
a
a
comprehensive
success,
attest
to
it
for
making
sure
that
the
use
cases
that
we
had
in
mind
for
provisions
are
working.
I
think
we
are
passing
the
compatibility
or
compliance
tests
that
one
is
part
of
the
ci
for
for
the
collector,
but
not
much
more
than
that.
D
C
D
C
Thanks
for
posting
a
project
link,
so
that
was,
I
didn't.
Have
that
and
that's
very
helpful.
I
I
think
it's,
but
would
is
it
fair
to
characterize
this
as
not
to
trivialize
what
I'm
about
to
say,
because
I
think
it's
still
a
lot
of
work,
but
this
is
more
like
sort
of
simple
matter
of
programming
stuff
where
it's
like.
There
is
definitely
work
to
be
done.
That
is
not
done.
C
There
are
resourcing
issues
etc
versus
some
kind
of
fundamental
incompatibility
that
we're
kind
of
dancing
around,
but
like
really,
this
is
never
going
to
scale
or
like
there's
some
semantic
issue.
That's
irresolvable,
or
something
like
that
like
this
is,
is
it
more
in
the
first
camp
than
the
second?
C
D
Have
to
check
that
out.
I,
my
understanding
is
that
we
had
one
still
one
major
incompatibility
and
I
can
confirm
that
for
the
next
call,
but
that
one
problem
is
not
a
feature
that
is
being
used
on
a
daily
basis
by
most
users.
So
is.
B
There's
one
specific:
if
I
remember
some
specific,
I
don't
know
if
it's
like
a
prometheus
style,
histogram
sketcher
bucket,
there's
one
area
where
they
think
it's
just
not
gonna
be
solvable,
but
it's
I
would.
I
hesitate
to
call
it
a
corner
case,
but
it's
not
a
significant
case.
It's
like
a
specific
type
of
distribution
that
you
use
in
prometheus.
That
will
be
very
problematic
to
pipe
through
the
collector
and
back
to
prometheus.
E
Yeah,
but
it's
it's
certainly
100
the
case
that
everything
we
are
doing
in
metrics
is
designed
with
prometheus
compatibility
as
an
explicit
goal.
So
all
of
the
api
and
sdk
design
that
we
did,
we
restarted
all
of
those
efforts
specifically
to
to
ensure
that
it
was
prometheus
compatible
and
that,
like
prometheus
people
were
involved
in
the
design
of
it.
So
yeah.
C
That's
kind
of
what
I
thought
I
mean
my
question.
The
outside
might
have
sounded
rhetorical.
I
didn't
I
I
think
it's
more
like
I.
I
just
wanted
to
bring
the
kind
of
perception
into
this
meeting.
I
guess
and
then
what
I'm
hearing
is
that,
like
there's
a
there's,
actually
a
meaningful
gap
between
perception
reality
and
I'm
not
really
sure
like
where
that
stems
from
this
person-
was
fairly
well
informed
about
prometheus
stuff,
like,
as
I
said,
they're,
not
just
like
a
user.
They
were
involved
in
a
more
like
literal
level.
C
Sorry
in
a
more
participatory
level
as
a
committer
and
stuff
like
that
so
yeah
I
just
I
don't
know
not
sure
what
we
need
to
do.
Maybe
yeah.
I
don't
know
like
that.
That's
like
definitely
the
story
that
I
that
I'm
familiar
with
ted
as
well.
So
I'm
confused
of
where
the
perceptual
issue
comes
from
yeah.
E
E
C
B
Yeah,
I
tend
to
agree
like
if
we're
not
regularly
in
those
calls
and
we're
not
and
generally
I
don't
know
if
that
would
be
the
most
productive
use
of
our
time,
given
all
the
things
we've
ahead
of
us.
Like
you
know
some
members,
many
members
of
prometheus
community
they're
not
actively
coming
out
to
check
on
our
status
regularly.
Why
would
they?
B
And
so
it
might
just
be
a
perception?
That's
from
the
past.
That's
that's
still
there
and
until
we
ship
that
perception
might
stick,
but
I
do
think
that
once
we
ship
that'll,
you
know
then
there'll
be
something
concrete.
That's
out
there,
that's
usable!
You
know
this
doesn't
come
out
of
malice.
It's
just
that.
You
know
they're
working
on
their
thing,
they're,
not
necessarily
checking
in
on.
E
Us
yeah,
I
I
think
a
big
shift
will
happen
when
we
complete
the
the
right
ahead.
Log
work
right,
because
when
that
work
is
done,
then
the
collector
can
actually
replace
a
prometheus
server,
which
is
actually
the
point
at
which,
if
you
are
a
prometheus
user
who
is
interested
in
like
open
telemetry
for
like
tracing
and
other
stuff,
when
you
would
like
actually
start
maybe
taking
on
an
open,
telemetry
component
in
your
stack,
because
it
just
reduces
the
number
of
things
you
have
to
run
at
that
point.
E
So
I
I
think
that
might
be.
You
know
when
that
kind
of
work
is
done.
We
can
should
start
making.
You
know
more
public
noise
about
our
prometheus
support.
It's
just
like
a
little,
maybe
a
little
early
right
now,
because
we
don't
have
like
a
big
like
helpful
use
case
to
point
to,
but
that
one
definitely
would
be
one.
C
C
Okay,
well,
that
was
helpful
for
me
and
I
I
kind
of
agree
about
the
having
something
that's
shipped
and
useful
in
production
will
probably
do
more
than
anything
else
to
address
the
perception
issues
which
I
think
are
probably
the.
E
Well,
yeah
yeah
yeah
I
mean,
and
in
general,
like
open,
telemetry
metrics
are
like
right
on
the
cusp
right
now,
right
like
we
have
working
prototypes
in
a
number
of
languages,
all
the
api
and
sdk
stuff
has
been
marked
as
stable,
and
so
it's
literally
just
a
race
to
to
get
the
release
candidates
out
at
this
point,
and
so
there
will
be
a
general
hollow
blue
about
open,
telemetry
metrics,
but
it's
just
like
a
little
early
at
this
point.
D
I'm
not
not
quite
sure
following
time,
so
I
mean
we
do
aim
and
have
a
promotional
support
as
a
first
class
system
for
open
telemetry
right,
and
are
you
saying
that
we're
going
to
focus
on
properties
after
after
ga
or
close
to
ga,
or
it
should
be
part
of
that
of
that
stage
or
when
you,
when
you
get
there,
it
should
have
a
first
class
yeah.
I.
E
Guess
it's
it's
already
like
we
already
have.
We
already
engaged
in
first
class
prometheus
support
and,
like
99
of
that,
comes
in
the
form
of
the
collector
being
able
to
process
process
prometheus
metrics
coming
in
like
act
as
a
prometheus
server
and
take
in
open
telemetry
like
otlp,
which
includes
metrics
as
part
of
its
data
stream
and
convert
that
into
prometheus
stuff.
In
other
words
like
to
take
our
push
model
and
have
the
collector
be
a
prometheus
server.
E
But
it's
like
we
have
not
been
making
a
lot
of
noise
about
open,
telemetry
metrics
just
in
general,
because
we're
not
like
quite
at
the
point
where
we
want
everyone
to
like
rush
over
and
start
using
it.
But
once
we
have
release
candidates
out
there
for
open
telemetry
metrics,
then
we're
going
to
be
talking
about
metrics
just
in
general,
and
so
there
will
be
that
will
just
get
into
the
zeitgeist.
E
And
I
think
it's
super
important
as
part
of
that
messaging,
to
really
emphasize
that
you
know
this
stuff
is
prometheus
compatible
and
like
that's
like
an
explicit
goal.
So,
but
we
just
like,
haven't
been
talking
in
public
a
lot
about
metrics
because
we
haven't
had
you
know
it's
just
like
slightly
too
soon.
D
Messaging,
we
should
define
very
well
what
what
primitive
support
means
is
it
acting
as
a
prometheus
server?
Is
it
just
doing
the
bridge
or
is
it
you
know?
Is
it
support
on
the
instrumentation
side?
So
should
these
orientations
expose
metrics
endpoints
the
way
that
prometheus
would.
C
Forth,
I
think
that's
a
very
good
point
rossi,
especially
since,
for
many
people
prometheus,
I
think
they're,
maybe
not
trying
to
be
very
precise,
but
what
they
mean
are
certain
protocols
not
actually
running
prometheus?
C
I've
heard
that
more
than
once
in
the
last
month
too,
like
oh
yeah,
for
me,
I
don't
actually
mean
prometheus
like
prometheus-
is
bad,
I'm
going
to
use
cortex
or
something
or
whatever
you
know,
but
it's
like,
but
they,
but
they
say
for
me
this
anyway.
Something
that
they
need
are
are
certain
conventions
and
protocols
right
so
and,
and
I
think
we
could
get
yeah
most.
What
I
hear
people
wanting
is
is
more
like
compatibility
with
the
engine
well,
at
least
from
an
open
telemetry
standpoint.
C
E
Actually,
so
to
clarify,
I
think
this
is
like
a
confusing
point:
prometheus
cert,
when
you're
using
something
like
cortex
right,
you're
you're,
using
some
some
big
distributed
system
to
deal
with
your
metrics.
E
There
is
like
an
essentially
a
collector-like
step
there,
where
you
are
aggregating
all
of
your
metrics
locally
to
something
that's
doing
the
prometheus
pull
model
and
whatever
and
then
from
that
point
shoveling
it
all
in
upstream,
into
some
big
data
ingestion
pipeline
and
those
things
that
you
use
at
that
step
are
called
prometheus
servers,
which
is
just
hella
confusing,
but
it's
basically
the
right
lit
right
ahead,
log
model
for
prometheus,
and
so
it's
about
the
work
we've
been
doing.
E
And
that's
where
we
see
the
primary
support,
I
mean
getting
each
individual
language
to
also
have
a
prometheus
exporter
of
some
kind
is
great,
but
we're
kind
of
presuming
people
are
running
open,
telemetry,
they're,
they're,
trying
to
pipe
out
traces
and
other
stuff
as
well.
So
the
the
first
leg
from
the
app
to
the
collector
is
probably
going
to
be
otlp,
where
it's
it's
sending
everything,
and
then
the
collector
would
replace
how
they're
currently
using
the
prometheus
servers
in
their
big
distributed
system,
so
that
that's
like
the
specific
architecture
we're
we're
aiming
aiming
for.
D
Sense
yeah,
it
does.
I
mean
the
thing
that
you
mentioned
on
the
cortex
side
of
things.
The
thing
that
aggregates
is
during
the
pull
model,
so
that's
technically
using
open
metrics
and
then,
when
it
goes
upstream,
it
is
doing
the
remote
right,
which
is
then
another
protocol.
It's
a
previous
protocol
and
those
are
like
the
most
common
ones.
But
then
there
are
few
things
within
primitives
like
the
exporters.
I
think
they
have
this
notion
as
well,
where
they
execute
an
external
process
to
get
metrics.
D
Out
of
you
know
the
whole
system
and
so
on
and
convert
into
and
get
this
data
into
this
discrimination.
So
it's
not
only
about
the
poll,
but
it's
also
kind
in
getting
metrics
all
the
way
in
other
ways
into
prometheus
itself,
which
then
goes
through
a
a
reward
right
fashion.
So
should
we
should
we
think,
or
should
we
consider
supporting
those
types
of
extensions
as
well
or
just
about
the
data
just
about
the
protocols.
E
I
mean,
I
think,
that's
what
we're
doing
right.
I
believe
I
could
be
wrong.
I
wish
we
had
a
lolita
here,
but
I
believe
the
collector
currently
supports
remote
right,
so
that
leg
is
done
and
then
the
remaining
leg
would
be
supporting
the
right
ahead
log,
which
is
the
other
model
that
you
tend
to
use
locally
or
closer
to
the
actual
applications,
and
so
that's
the
work,
that's
still
outstanding,
because
it's
a
little
more
complicated
from
what
I
understand.
C
And
part
of
me
wonders
is
just
a
misuse
this
meeting
and
I
should
just
go
at
rtfm
or
something
but
like
my
understanding,
was
that
the
hotel
collector
today
can
take
a
prometheus
configuration
and
do
the
pulling
bit
not
using
otlp,
where
it
pulls
whatever
is
in
the
config
to
like
grab
stuff
and
pull
it
in.
That's
a
is
that
correct
and
then
well
yeah.
Is
that
correct.
F
F
C
C
Agree
that
people
adopting
open
telemetry
for
tracing
might
also
adopt
it
for
metrics,
but
I
absolutely
would
stand
behind
the
statement
that
a
lot
of
people
are
like.
I
want
to
use
open
telemetry
for
downstream
collection,
hotel,
collector,
post
collector
stuff,
I'm
perfectly
fine
with
my
brownfield
metrics
instrumentation,
and
I
have
no
interest
in
taking
that
on.
So
I
want
to
make
sure
that
that's
also
viable
things
as
much
as
I'd
be
happy
for
people
to
adopt
hotel,
metrics,
otlp
stuff
to
export
out
of
their
process.
C
E
Yes
and
and
the
goal
is
to
to
to
for
the
collector
to
play
all
of
those
roles-
it's
just
I
in
other
words,
you
have
a
scraper,
that's
grabbing
stuff.
You
have
a
right
ahead
log
and
then
you
have
remote
right,
like
that's
kind
of
like
the
the
prometheus
pipeline,
and
I
believe
the
goal
is
for
the
collector
to
be
able
to
do
all
three
of
those
scraping,
write
ahead,
log
and
rip
out
right,
but
I'm
not
a
prometheus
expert
and
I've
not
been
working
on
that.
E
So
I
can't
tell
you,
unfortunately,
I
believe
both
the
scraping
and
the
remote
right
parts
are
are
done
and
working
and
it's
just
the
right
ahead
log
and
so,
at
the
end
of
the
day,
you're
gonna
be
able
to
do
everything
you're,
saying
ben,
which
is
like
I
just
I'm
just
sending
prometheus
stuff.
I
don't
want
to
touch
my
prometheus
metrics,
but
I
would
like
to
use
collector
magic
to
do
something
with
them
for
some
reason,
and
we
want
to
support-
and
we
do
support
that
use
case
as
well.
E
Yeah,
so
I
think
prometheus
people
are
going
to
be
happy
with
what
we
what
we've
done
like,
but
yeah.
We
just
haven't,
haven't
done
like
a
big
push
yet,
and
I
think
once
the
right
ahead.
Log
work
is
complete,
we'll
be
able
to
talk
about
it
coherently
and,
as
we've
seen
like
in
the
absence
of
any
of
that,
it's
easy
to
to
write
your
own
impression
into
the
void,
which
is
not
going
to
be
as
positive.
As
you
know,
the
one
that
we
get
if
they
talk
to
us.
C
Yeah
yeah,
I
think
you
know,
since
we
have
that
dot,
describing
our
engineering
values
and
so
on.
I
think
the
decoupled
piece
is
pretty
important
here.
I
think,
if
you
think
of
open
telemetry,
as
you
know,
kind
of
a
toolbox
of
things
that
related
telemetry
and
prometheus
community
can
take
or
leave
whatever
benefits
them
can
be
seen
as
a
net
positive.
I
think
if
it
feels
like
something,
that's
meant
to
be
a
land
grab
in
some
zero-sum
game
that
it's
intrinsically
threatening.
E
But
it's
easy
to
assume
that
right,
like
that,
would
be
the
natural
assumption
of
anyone
that
if
it's
a
new
metrics
product
system
thing,
therefore,
and
it's
somehow
different
from
prometheus.
Therefore
it's
in
competition
with
prometheus
and
it's
gonna
replace
it.
But
like
that's
not
what
open
telemetry
is.
We
are
just
a
telemetry
system
that
is
trying
to
be
able
to
shovel
data
into
like
everything
that's
out
there
currently
and
that
100
includes
prometheus
yeah.
F
Yeah
no
problem,
they
seem
like
they
both
are
getting
a
fair
number
of
approvals.
I
don't
know
who
exactly
merges
that
and
how
many
approvals
we
wait
for
or
whatever,
but
I
you
know,
I
don't
want
to
be
the
one
to
merge
them
since
I
wrote
them,
I
feel,
like
that's
bad
form,.