►
From YouTube: Policies And Telemetry WG Meeting - 2020-10-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
All
right,
can
you
see
my
screen?
Yes,
very
good
yeah.
I
just
wanted
to
quickly
show
what
I've
been
working
on
downstream
and
maestro,
and
we
discussed
this
before
when
a
few
months
back.
Actually
when
it
was
still
a
topic,
how
to
extend
the
envoy
filter
api.
A
Well,
actually,
that's
what
came
with
it
before
we
were
talking
about
how
to
create
or
what
kind
of
api
to
create
to
enable
wasm
extensions
to
to
proxy
into
istio
in
general-
and
I
mentioned
back
then
that
I'm
not
entirely
happy
with
the
envoy
filter
approach,
because
I
wanted
something
that
was
hands-on
and
easy
to
use
and
doesn't
require
users
to
know
the
internals
of
istio
as
much
as
you
know,
knowing
the
the
name
of
the
wasm
filter
within
onward,
it
is
used-
and
you
know
knowing
the
structure
of
the
filter
config
of
envoy.
A
A
So
I
have
a
control
plane
running.
I
have
an
http
bin
running
I'll
zoom
in
real
quick.
A
A
A
So
this
is
what
the
custom
resource
looks
like
that
we're
using,
as
you
can
see,
it's
it's
fairly
simple,
so
you
set,
you
define
a
config.
You
tell
it
where
to
find
the
image
that
contains
the
extension,
so
this
is
similar
to
what
solo
io
have
done.
So
basically,
it's
using
an
a
container
image
to
ship,
the
extension
it
has
the
wasm
module
and
some
metadata.
It's
not
the
same
format
as
solo.
I
o,
but
we're
planning
to
be
compatible
with
both.
A
So
this
is
something
that
we're
using
for
now
and
will
be
shipping
as
a
tech
preview.
In
the
upcoming
2.0
release,
I
can
send
you
more
details
on
the
image
format
later,
but
the
important
part
is
really
the
this
service
mesh
extension
resource,
so
there's
a
phase
which
is
pretty
much
like
what
we
have
in
the
envoy
filter.
A
Now,
where
we
can
add
things
into
specific
parts
of
the
filter
chain
by
selecting
a
phase,
then
there's
something
that
we
don't
have
in
onward
filter,
which
is
a
priority,
so
the
higher
the
priority
the
earlier
in
the
filter
chains
phase.
This
will
be
added.
So
if
you
have
two
extensions
with
this
that
are
in
this
phase,
the
one
with
the
higher
priority
will
be
injected
first
in
the
filter
chain
and
the
one
with
the
lower
priority.
A
After.
If
it's
the
same,
I
think
I
implement
something:
that's
based
on
the
name
or
something
so
it's
still
deterministic,
and
then
you
have
the
workload
selector,
which
is
pretty
much
the
same
as
an
onboard
filter
resource.
A
This
and
you
see
it's
a
normal
http
bin
and
the
returned
headers
are
fairly
normal
and
now
I
can
basically
apply
this
to
the
test
namespace
where
http
bin
is
running
and
then
because
the
workload
selector
it
will
select
that
workload
and
we
can
curl
again
it's
not
there
yet
probably
still
downloading
the
image,
and
then
we
have
it
this
custom
header
test,
so
basically
behind
the
scenes.
A
This
has
now
there's
two
components
to
this:
there's
the
wasn't
cache
here
that
will
actually
go
download
the
container
image
and
make
the
wasm
module
available
within
the
mesh
and
then
there's
a
patch
to
sdod.
That
will
so
this.
This
component
then
writes
to
the
status
of
this
resource.
We
can
actually
check
that
here.
So
we
see
the
status
below
here.
A
A
So,
whenever
there's
there's
an
a
service,
mesh
extension
with
ready,
true
and
a
url
seod
will
actually
pick
that
up
and
distribute
it
to
the
proxies
based
on
the
workload
labels
when
they
match-
and
this
is
also
done
before
evaluating
envoy
filters
so
that
as
a
power
user,
you
still
have
the
possibility
to
change
the
config
that's
generated
by
scod.
So
if
you
want
to
have,
if
you
want
to
configure
something
about,
this
wasn't
filter
that
is
not
offered
by
this
resource.
For
example,
runtime
is
currently
not
offered.
A
You
can
do
that
using
a
normal
envoy
filter
that
will
actually
match
this
thing
in
the
filter
chain.
You
can
manipulate
it
and
yeah.
That's
actually
that's
just
about
what
I
wanted
to
show.
I
just
wanted
to
show
this
to
you
guys
and
figure
out.
Is
this
something
that
you
can
see
us
wanting
for
upstream
as
well,
because
I
I
would
be
very
interested
to
actually
bring
something
like
this
upstream.
A
I
know
there's
there's
work
ongoing
for
a
extension
server
that
I've
seen
it
works
a
bit
differently
than
what
I've
done,
but
the
the
internals
are
not
as
important
to
me
as
as
the
api.
If
we
can,
if
we
could
have
something
like
this,
I
think
that
would
be
amazing
because
it
enables
a
very
different
usage
of
extensions
than
having
to
tell
people.
A
You
know
you
have
to
use
this
envoy
filter
and
you
basically
have
to
make
manual
patches
to
the
envoy
config
that's
generated
that
doesn't
feel
like
real
first
class
support
to
me,
and
I
wanted
something
that
is
a
first-class
api
that
makes
it
quick
and
easy
to
actually
deploy
an
extension
yeah.
That's
that's
pretty
much
it
it's
not
it's
not
even
10
minutes.
I
guess.
B
This
looks
I
mean
this.
This
does
look
this
look.
This
definitely
looks
very
very
user
friendly
and
I
mean
yeah.
We.
We
definitely
want
this
in
industry
right
like
not,
maybe
not
exactly
in
this
implementation
or
this
form,
but
like
something.
That's
more
consumable
like
you
have
in
in
your
api.
So
I
I'm
I'm
definitely
very
supportive
of
like
having
something
like
this
that
the
I
think
the
like.
B
The
challenge
is
going
to
be
deciding
of
the
stuff
that
we
have
to
decide
for
all
other
apis
as
to
how
do
overrides
work
and
what
happens
when
multiple
workloads
are
selected,
but
by
the
same
it
it's
kind
of
the
same
thing
that
onward
filter
itself
has
right.
This
is
essentially
doing
the
same
thing
and
it's
abstracting
it
one
level
higher,
but
but
I
think
like
from
usability
perspective.
This
is
really
nice.
A
Yeah
I
mean
I
I
can.
I
can
write
a
doc
that
that
basically
outlines
what
what
I
have
in
mind.
As
I
said,
the
implementation
is
not
as
important
to
me.
I
don't
want
to.
I
want
to
push
a
certain
implementation
or
anything,
but
I
would
really
like
us
to
have
an
easily
consumable
api
like
this,
but
for
that
I
mean
a
lot
of
things
have
to
fall
in
place
right
we
have
to.
If
we
want
to
use
a
container
image
format,
we
have
to
agree
on
a
format.
A
There
has
to
be
a
deployment
mechanism
to
make
it
available
to
proxies,
which
could
be
the
extension
server.
That's
in
the
proxy
repo
yeah.
So
there's
there's
a
few
things
right
and,
of
course,
as
you
said,
the
behavior
of
the
resource
itself,
how
does
it?
How
does
it
behave
when
there's
multiple
of
them
and
stuff
like
that.
B
Yeah,
so
so
I
think,
like
a
part
of
it
is
since
solo
has
started
the
the
spec
right
like
agreeing
on
on
that
spec.
B
That
includes
all
the
metadata
that
we
want
and
just
kind
of
everyone
agreeing
on
that
would
would
be,
I
think,
like
one
of
the
easier
directions
to
take,
but
but
yes
like
those
are
exactly
the
the
kinds
of
things
that
we
need
to
solve
and
solo
has
so
th.
This
one
is
is
using
you
have
your
own
http
server
running
in
the
cluster
right
right,
like
a
wasm,
yeah,
okay,
so
so
so
in
in
cluster
cache.
B
But
it
is
not
a
demon
set.
It's
just
a
regular
service.
C
C
Yeah,
so
I
think
comparing
like
having
a
write-up
of
just
the
two
different
approaches,
as
sort
of
evidence
of
what's
being
done
and
informing
an
istio
approach
at
a
high
level
right
and
then
then
we
can
dig
into
the
specs
on
the
image
format,
and
you
know
how
how
the
bits
get
served
right,
I
think,
would
be
a
great
start.
A
C
A
C
C
A
Yeah,
hopefully,
hopefully
we'll
be
able
to
so
we
have.
We
have
an
internal
team,
this
the
three
scale
team
and
they
they're
currently
using
a
mixer
adapter
to
connect
istio
to
three
scale
and
they
are
in
the
process
of
migrating
to
wasn't
filter
and
they
will
be
using
this
api,
basically
to
let
users
install
their
their
adapter
into
the
mesh.
A
So
we'll
have
kind
of
a
dog
fooding
mechanism
in
place,
so
they
will
be
using
this.
They
will
also
probably
find
some
loose
ends
and
problems
with
it
and
yeah.
It's
going
to
be
tech
preview
in
our
upcoming
version,
and
so
that
means
we
don't
have
strict
guarantees
on
the
api,
we're
open
to
changes
and
then
for
the
next
minor
version.
After
that
we
want
to
have
something
that
is
stable
and.
A
I
would
like
us
to
have
something
that
is
in
sync,
with
with
upstream
so
yeah
I
I
I
will
very
much
carry
like
anything
all
the
learnings
over
to
to
this
group.
If
that's
what
you'd
like
to
see.
C
B
Yeah
and
then
we
should-
we
should
put
this
on
for
1.9
roadmap
to
have
to
basically
have
this
functionality
in
upstream
stu
right
like
in
maybe
not
in
the
exact
same
form,
but
essentially
this
functionality
in
in
history
itself.
So
I
think
that,
like
that
aligns
with
even
daniel's
goals,
right
of
having
close
yeah
having
it
aligned
with
upstream.
C
Okay,
well,
thank
you.
That
was
that
was
super
super
interesting
and
much
much
better
than
our
typical.
Just
look
at
doc's
meeting
moments.
Does
anyone
else
have
anything
else
they
want
to
share
with
the
group
while
we're
all
yeah?
Okay.
The
only
other
thing
I
have
on
the
agenda
really
is
just
reminding
everyone
to.
Please
take
a
look
at
the
telemetry
api
proposal.
C
I'm
going
to
start
circulating
it
to
a
broader
history
audience
soon,
just
because
we
were
supposed
to
have
this
done
by
1
8,
and
so
I
want
to
get
to
a
good
spot
in
the
next
couple
of
weeks.
I
know
niraj,
you
had
added
some
comments
this
morning
and
I
haven't
had
a
chance
to
fully
suggest
them,
but
I
I
would
welcome
many
more
comments
on
that.
D
Yeah,
it's
looking
in
good
shape.
I
my
broader
comment
is
about
bleeding
of
concer,
like
blending
of
concerns
between
the
operator
and
the
application
owner
role
here.
Assuming
this
api
is
more
focused
towards
a
name
space
or
a
workload
owner,
which
I
think
that's
what
you're
trying
right
so
address
my
comments
and
then
we
can
also
chat
offline,
okay,.
C
Sounds
good
and
then
I
think
here's
a
nice
segue
mandar
the
previous
conversation
about
what
to
do
for
one
nine
and
what
we
wanted
to
try
to
achieve.
I
threw
down
some
thoughts
to
sort
of
scaffold
the
discussion,
but
I'm
very
much
interested
in
what
others
want
to
see
out
of
one
nine
release
and
things
that
we
should
try
and
shoot
for
this
holiday
season.
Basically,
so
I'll
open
the
floor
for
discussion
there.
B
So
so
I
think
the
out
of
out
of
mesh
telemetry
half
of
it
is
done
in
this
release
right.
The
other
half
still
remains.
E
Yeah,
I
mean
we
need
to
evaluate
whether
we
want
like
how
much
do
we
want
to
achieve
the
other
side
right.
It's
going
to
be
a
quite
big
effort.
I
mean
adding
the
central
like
adding
demanded
query
support
is
to
the
seems,
like
a
heavy
lift,
so
I
mean
it's
gonna,
take
like
a
release
or
two
to
finish.
That
and
add
quite
a
lot
complexity,
so
I
mean
it's
a
great
to
have,
but
I'm
not
sure
what
do
you
think
to
add
this?
E
It
doesn't
matter
justify
the
effort
for
it
I
mean
so
far,
all
the
community
that
all
the
issue
we
get
from
github
is
about
client
side,
missing
management,
because
client
side
captures
all
the
requests
earlier
that
doesn't
reach
server.
So
it's
kind
of
more
important
than
server
side
basic
manager,
though
so
that's
why
I
like,
I
think,
having
the
cluster
and
phone
label
would
be
great
for
one
day,
but
I'm
not
sure
how
much
like
at
least
I
don't
have
much.
E
D
I
agree
with
you
peter
that's
why
I
think
we
were
focusing
on
getting
this
half
in.
I
mean
if
you're
suggesting
a
wait
and
watch
strategy
here.
So
we
can
see
if
this
use
case
is
emerging
and
then
decide
either
mid
one
nine
or
after
one
nine.
D
B
C
I'll
just
say
I
don't,
I
haven't
looked
at
the
issue
that
was
opened
related
to
this.
Was
that
only
client
side
or
was
it?
Was
it
source
side
in
terms
of
the
nature
of
the
the
actual
issue?
That's
the
one
thing
I
want
to
make
sure
like
if
we
say
we're
going
to
wait
and
see,
but
some
we
already
have
evidence.
E
I
think
most
of
them
it's
just
about
client-side
mismata
there
I
I
can.
I
can
check
double
check,
but
I
don't
remember
I
just
won't
get
up.
I
don't
see
any
complaining
about
so
we're
missing.
I
didn't
do
that
yet
so.
D
E
D
If
you
bring
back
a
list
of
issues,
maybe
and
or
just
write
it
in
this
doc
and
say
you
know,
95
of
them
are
talking
about
client
that
pretty
much
will
you
know,
satisfy
doug's
concern
here.
E
B
The
config
annotation
of
metrics
we
have
like
we
have
pushed
it
out,
then
dropped
it.
C
B
Well,
but
many
vendors
do
have
backup
history
of
config
itself
right.
B
So
if
so,
if
we
have
a
way
in
sto
to
use
whatever
facilities
are
available
outside
istio,
then
then
it
is
useful
and
actually
even
without
that.
B
It
is
useful
right
because
you
you
want
to
know
like
let's
say
that
you
you
create
a
destination
rule
and
you
expect
all
the
traffic
to
go
through
the
destination
rule,
and
then
you
find
out
that
none
of
it
is
or
like
not
enough
of
it
is
or
something
like
that
and
like
that
would
be
a
reason
for
you
to
go
and
see
if
something's
being
overwritten
or
something
like
that.
D
So
that
use
case
is
for
just
in
time
debugging
and
not
looking
over
history,
so
we
can
have
different
solutions
for
that
particular
problem.
Right.
B
It
was
is
what
just
added
here
correct.
D
Yeah,
okay,
so
I
think
that's
the
key
thing
that
we
should
understand.
Are
we
trying
to
help
just
in
time
debugging,
where
you
don't
understand
whether
your
particular
configuration
is
taking
effect
or
not,
or
we
want
to
solve
customers
looking
back
in
time
and
saying?
Okay
at
this
point
of
time,
which
configuration
was
in
effect,
for
this
particular
request?
F
Yep,
would
it
be
good
to
have
a
use
case
around
some
of
this
stuff
so
that
we
could
say
this
is
what
we're
trying
to
do,
and
then
we
can
drive
into
solutions,
because
this
is
the
way
we're
talking.
It's
sounding
like
this
is
a
solution
and
we're
finding
the
problem
where
it
applies,
or
at
least
it's
not
clear
to
me
where
it
applies.
D
D
Affected
your
traffic
flow
right
now.
This
is
tying
two
things
into
one.
If
that's
not
a
use
case
that
anyone
really
wants,
we
shouldn't
take
on
that
burden.
I
do
feel
like
some
people
have
asked
for
it.
I
just
don't
know
how
actually
useful
it
is
it's
kind
of
complicated
to
get
a
good
use
case.
Out
of
this.
To
be
honest
right,
you
need
something
like
a
stack
driver
or
whatever
google's
equivalent
is
for
time
machine.
C
D
B
We've
had
that
for
a
while
right,
yeah
yeah
we've
had
that
for
a
while,
but
it
it
it
it's
basically
like
tying
that
to
any
any
form
of
telemetry.
That's
like
that.
That
part.
That
part
is
missing
and
I
think
tracing
I.
I
agree
kind
of
answers
the
question
more
head-on,
because
you
can
actually
force
a
client-side
trace
and
then
it
will
go
through
the
mesh
and
it
will
tell
you
yeah,
which
exact
configuration
artifacts
were
involved
in
making
that
happen.
C
Yeah
yeah,
I
guess
I
was
thinking
about
it
from
the
other
side
right.
It's
if
I
have
all
this
telemetry
about.
What's
happened
in
my
mesh
right
and
what
traffic
looks
like
and
I
have
a
config
that
I
want
to
apply.
It'd
be
nice
to
be
able
to
simulate
or
somehow
understand
what
the
impact
should
look
like
before
applying,
and
then
you
do
some
sort
of
comparison.
I
mean
that's
super
so
difficult.
B
So
linker
d
has
has
this
like.
Has
this
feature,
which
is
that
you
can
actually
put
override
configuration
as
a
header
in
the
request
itself
and
then,
as
the
request
goes
through
the
mesh
that
override,
which
is
carried
with
the
request,
will
take
over
and
like
do
something
else,
but
it
it
it
it
it's
a
it's.
A
very
cool
demo
feature
I'm
not
sure
how
much
people
will
actually
use
it
right
I
mean
we
have
like
canary
cicd,
like
all
kind
of
more
mainstream
ways
of
doing
the
same
thing.
F
D
Absolutely
yeah:
it's
it's
a
bandit
for
the
problem
that
you're
saying
rob
that
people
are
scared
to
make
changes,
because
those
changes
are
complex
to
understand
and
then
once
you
apply,
you
don't
know
what
will
break.
G
I
mean,
I
think
there
is
a
a
disconnect
between
what's
happened
in
the
configuration
and
what
and
what's
happening
in
the
telemetry
right.
So
it's
it's.
It's
pretty
easy
to
go
back
into
prometheus
and
look
at
historical
traffic,
for
example,
or
response
times
or
whatever
it
is,
but
tying
that
anomalies
that
you
may
see
there
to
the
configuration
at
the
time
is
is
the
problem
I
I
just
don't.
I
don't
think
that
it's
necessary
to
try
to
tie
config
to
the
metrics
perspective.
G
B
G
G
Well,
I
mean
I'm
thinking
about,
for
example
like
if
you,
if
you
go
in
keali
today,
you
can
do
like
a
what
we
call
a
graph
replay
right,
so
you
can
go
back.
You
can
pick
some
time
period
in
the
past
that
you
want
to
re-examine
over
and
over
and
you
can
gen
you
can
watch
it
happen
right
almost
like
a
like
a
you
know,
a
video
recording
and
you
can
see,
for
example,
here's
the
time
where
all
of
a
sudden,
my
traffic
turned
red.
You
know
what
we
don't
have
today.
G
Is
this
other
view
timeline
view
per
perspective?
Where
you
could
say?
Oh
look.
At
the
same
time,
you
know
there
was
a
change
to
the
virtual
service,
which
is
what
I
think
you're
trying
to
do
here
right.
B
Yes,
but
but
actually
the
way,
the
way
you
you
put,
it
is
actually
like
cleaner
and
it's
more
aligned
with
like
automatic
configuration
management
where
the
event
stream
of
configuration
changes
have
their
own
time
series.
C
Well
yeah:
this
reminds
me
of
I
mean
work
that
was
sort
of
done
a
while
back
on
config
state
metrics
right,
so
you
could
seo
could
provide
something.
That's
watching
and
providing
you
know:
virtual
service,
metrics
and
destination
rule
metrics
for
thanks
for
all
the
configs
on
the
state,
and
that
would
give
you
stuff
inside
of
prometheus
and
not
require
some
other
vendor
to
provide
that
sort
of
information
for
for
everyone,
and
we
could
go
back
to
doing
something
like
that.
C
G
B
Yeah,
I'm
not
sure
amanda
what
you
think
it
was
yes,
no!
No!
No,
I
think
like.
I
think
that,
for
for
for
the
actual
use
case
that
we
just
described,
having
two
separate
streams
that
you
can
correlate
post
facto
is
is,
is
very
much
useful
and,
like
duck
said,
config
config
state
metrics,
so
is.
Is
that
something
we
want
to
consider
for
for
one
nine?
I
I
think
I
I
I
would
like
just
like
this
whole
section
right.
B
We
probably
need
to
start
with
gathering
how
much
user
appetite
there
is.
B
B
B
If,
if
there
is
another
survey,
that's
going
out
and
now
we
are
going
to
have
them
quarterly,
so
I
don't
know
if
this
level
of
granularity
is
okay.
B
C
Okay,
are
there
other
items
that
we
want
to
focus
on
in
one
nine,
I
feel
like
there
were
things
from
one
eight
that
we
sort
of
took
half
measures
on.
C
E
E
B
B
C
So
it
was
in
that
other
dock.
I
wrote
on
sort
of
long-term
changes
to
the
metrics
that
we
deploy.
I
think
we
should
make
the
cluster
labels
permanent
and
one
nine
and
not
just
if
you're
in
multi-cluster
scenarios.
I
think
that
should
be
something
I
mean
it's
a
small
change,
but
I
think
that's
the
only
thing
in
multi-cluster
that
I'm
aware
of
and
maybe
some
documentation
so
okay.
C
We
do
we
want
to
take
some
time
for
addressing
open
p0s
from
prior
releases.
I
feel
like
we've
got
a
lot
of
backlog
issues
and
I
don't
know
if
we
ever
prioritize
them
appropriately,
so
I'll
put
a
plug
in
for
that
there.
But
I
don't.
I
don't
know
if
there's
a
good
way
of
doing
better.
B
B
B
C
H
H
Those
will
be
ready,
yeah
yeah,
I
mean
I'm
not
sure.
Is
this
one
line
yeah
one
line.
H
B
C
E
E
Should
we
should
we
like
track
more
specifically
what
kind
of
goal
we
want
to
reach
for
muscle
like
sigma
or
should
decide
that
in
later
medium,
I
mean
perfect
distribution,
monitoring
or
seems
important,
but
seems
like
we
don't
have
a
very
specific
quantitative
number
like
for
distribution
like
oh
making,
ecds
ready
or
not
constant
delay,
or
something
like
that
or
some
x
seconds
of
delay
or
for
perf
how
much
memory
we
have
into
like
memory
overhead
we're
going
to
introduce
with
also
module
or
things
like
that.
E
I
think
I
think
we
need
to
refine
this
go
a
little
bit.
Otherwise
I
think
the
vosm
extension
will
will
slice
another
release.
B
I
mean
we
have
some
external
dependencies
there,
but
but
yes,
so
so
there
is
yeah
high
memory
usage
is
it's
definitely
one
of
the
the
kind
of
big
deep
work
items
yeah,
which
we
should
track
here.
Yeah
yeah,
I
mean
like
oh
yeah,
so
some
people
here
are
involved
in
that
so
okay,
so
yeah.
I
agree.
Let's
track
it,
it.
C
E
Yeah-
and
I
think
doc
mentioned
a
good
quality-
we
needed
to
have
a
something
like
vm
and
cmi
where
they
have
a
motorcade,
so
they
have
the
beta
promotion
plan
that
leads
to
all
the
work
items
and
tracking
issues
and
like
the
progress
on
them
and
the
target
release,
etc.
That
would
be
really
helpful.
I
think.
B
B
We
don't
have
we
so
not
for
telemetry
like
I,
I
that
there
is
not
an
impending
goal
or
a
need
to
enable
it
for
telemetry.
What
we
need
to
do.
The
goal
is
for
wasm
to
be
consumable
for
the
kind
of
more
heavily
used
or
the
more
use
cases
which
appeal
to
awesome,
which
are
like
either
bespoke
extensions
that
customers
write
on
their
own
or
some
vendor
extensions,
so
it
it
has
to
be
so
so
the
point
is,
I
don't
think
we
will
make
a
change
in
istio
to
say.
B
B
B
Here
rob,
I
think,
robust
question.
E
At
least
for
c
plus,
first
and
last,
I
think
the
two
chain
is
good,
most
mostly
good.
I
mean
it
should
be
ready
for
production
youth
usage,
but
for
other
languages
like
golden
the
teacher
might
not
be
as
mature.
I
mean
lots
of
people
are
using
rust
and
surplus
was
compiled
by
some
module
for
their
no
web
application.
I
think
so.
I
assume
that
it
should
be
a
good
for
us
as
well.
F
Yeah,
I
guess
my
question:
there
was
more
what
languages
are
our
users
most
predisposed
to
right?
So
if
they
were
writing
legacy
envoy
plug-ins,
but
that
would
make
sense
c,
plus
plus
is
there.
But
you
know
what
are
the
developers
that
would
be
doing
this?
Are
they
going
to
be
coming
from
a
c
plus
or
a
rust
background,
or
are
they
just
kind
of
forced
into
that,
because
those
are
the
most
mature
tool
chains.
I
No,
no
one,
no
one
has
a
rust
background.
So
that's
wait
but
yeah
yeah,
but
I
think
it's
one
of
the
mature
tool
chains
right
or
b
rust,
so
right
so
for
so
for
small.
B
For
small
mapping
type
plugins
right,
which
which
are
connecting
a
few
things
and
doing
some
simple
manipulation
at
least
I
expect
more
people
to
use
assembly
script
because,
like
that's,
what
is
closer
to
javascript
you,
you
don't
want
to
write
c,
plus
plus
code
to
like
manipulate
some
headers.
Do
some
string
processing
on
it
and
then
set
some
other
headers
like.
If
that's
all
you,
you
are
going
to
do
the
like
the
more
involved,
plugins.
B
So
I
think
unfortunately,
that's
where
we
are
and
like
tiny
go
support
is
kind
of
a
little
bit
away.
Assembly
script.
Support
is
actually
also
maturing,
but
I
have
not
like
I.
I
don't
have
any
first-hand
experience
of
it.
I've
I've
just
been
watching
kind
of.
What's
going
on
on
solo,
to
know
that
assembly
script
is
kind
of
coming
up.
C
B
C
And
I
told
some
people
this
yesterday,
but
I've
been
making
an
attempt
to
do
bug
triage,
but
I
there's
a
lot
of
issues
in
github,
so
if
any
maintainers
on
the
call
have
free
cycles
and
see
issues
that
aren't
appropriately
labeled
or
prioritized,
please
take
a
stab
at
them.
Try
and
get
them
organized.
That's
a
big
push,
something
like
two-thirds
of
the
issues
in
github
weren't
triaged
as
of
yesterday
or
two
days
ago,
so
we'd
like
to
get
that
sorted.
So
I
I
promise
the
working
group
leads.