►
From YouTube: Policies and Telemetry WG Meeting - 2020-08-26
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
B
Yep,
okay,
well
yeah,
so
we
can.
We
can
come
back
to
the
road
map
when
30
minutes
are
left,
but
we
can
start
with
the
rest
of
it.
Yeah.
D
E
Yes,
so
I
put
that
on
a
few
weeks
ago,
I'm
glad
someone's
looking
at
it.
I
will
keep
through
through
there.
E
B
B
C
A
Sure
so
yeah!
So
so,
if
you
look
at
the
link
in
pr,
it
has
a
server
new
field
into
the
proxy
config
which
specifies
the
stats
inclusion
we
are
with
based
on
the
stats
name,
surface,
prefix
and
logic's
expression,
and
without
this
like
the
current
way,
we,
what
is
more
always
stats,
is
to
israel
annotations.
A
So,
basically,
if
we
found
that
some
part
is
in
that
state,
I
want
we
want
to
debug
it.
We
are
going
to
add
annotation
to
that
part
and
but
that
only
works
for
sidecar,
and
if
you
want
to
manipulate
this
for
gateway,
we
need
to.
We
need
to
add
the
steel
meta
in
one
variable.
A
So
basically
the
problem
right
now
is
that
one
gateway
and
sidecar
does
not
have
a
consistent
way
to
configure
our
stats
and
two
is
that
we
don't
have
a
global.
We
don't
have
a
way
to
globally
enable
some
stats.
A
So
that's
why
I'm?
I
came
up
like
this
pr,
like
I
make
this
vr
so
that
we
have
the
proxy
config
to
control
global
stats
inclusion
and
we
can
do
per
workload
all
right
and
the
and
the
way
to
override
would
be
the
same
at
gateway
and
sidecar
so
and
doc
mentioned
that
this
pr
might
have
implication
on
the
new
telemetry
api,
because
proxy
configuration
is
one
place
that
we
are
considering
to
add
telemetry
new
telemetry
api
control.
A
So
I'm
not
sure
whether
I
should
hold
on
this
vr
or
and
wait
for
the
shape
of
the
new
api
and
see
whether
it
is
due
like
whether
it
makes
sense
is
to
add
this
make
sense
to
add
this
into
the
new
temperature
api,
or
shall
we
just
submit
this
as
it
is
right
now
so
hope
to
get
some
feedback
on
this
yeah
talk?
What
do
you
think.
C
C
A
Yeah
this
this
is
static
config,
so
like
the
like
to
me,
telemetry
api
is
something
that
we
want
to
configure
dynamically
right.
So
I'm
not
sure
whether
this
this
would
make
sense
to
be
part
of
parliamentary
api
or
not
so.
B
Well,
so
so
telemetry
api.
We
wanted
to
be
both
right.
We
want
the
so,
the
actual
final
api.
Yes,
I
agree
it's
kind
of
dynamic,
but
the
whole
picture
should
and
does
include
telemetry
defaults
and
telemetry
overwrites
or
basically
I
mean
those
are
the
two
things
right.
This
is
the
default
right.
That's
that's!
Why
you've
put
it
here
and
this
is
the
default.
B
So
is
this
the
default,
the
same
default
for
gateways
and
side
cars
are
different,
yes
yeah,
I
think
so,
but
but
I
think
one
of
the
things
is
that
many
times
you
actually
do
want
different
things
at
gateways
inside
cars.
B
B
If
we
choose
to
do
something
different
in
the
telemetry
api,
then
this
will
still
be
somewhat
of
a
one-off.
So
I
I
think
that,
like
I,
I
completely
understand
why?
Why
why
you're
doing
it,
the
the
istio
meta,
json
thing
or
mr
meta
json
stats
thing
is
like
is
difficult
to
follow
for
for
many
people
who
want
to
add
this
to
the
to
the
gateway.
So
I
still
understand
that,
but
it
it.
A
F
There's
been
some
people
requesting
changes
to
bootstrap
but
applied
to
using
the
filter.
B
F
D
B
B
A
Yeah,
so
so,
basically,
the
desert
agenda
is
since
we're
going
to
re,
since
the
mixer
has
been
removed.
The
whole
like
policy
enforcement
section
in
steel
dial
task
doc,
is
like
needs
to
be
updated
or
removed.
A
So
I'm
wondering
shall
we
replace
content
in
it
with
web
assembly
based
solution
like
it
doesn't
have
to
be
exactly
the
same,
but
I
mean
we
probably
want
to
provide
or
add
some
tasks
with
website
either
web
assembly
based
filter
or
like
avoid
native
limiting
api,
for
example,
so
yeah.
This
is
just
a
question
like,
since
we
are
early
in
the
release
cycle,
I
think
if
we
want
to
make
major
changes
to
the
doc,
we
never
will
better
prepare
it
early
in
the
cycle.
A
So
so,
basically
the
task
right
now
is
really
limiting.
I
think
we
have
an
alternative
solution
to
use,
avoid
limited
re-limiting
and
the
other
one
is
denials
on
white
and
black
beasts.
I
think
that
is
also
one
thing
that
we
could
do
with
a
webassembly
filter
like
we
can
just
replace
it
with
webassembly
filter,
so
so
as
the
control,
headers
and
routing.
A
B
So
so
nupur
has
has
been
working
on
or
she
actually
already
has
a
pr
out
that
documents
and
ads
tests
for
x,
dot
c.
B
B
I
mean
I
guess
denial
can
just
be
done
through
our
back
or
we
could
do
I
mean
it,
so
it
would
be
good
to
include
it
as
an
example
of
web
assembly,
potentially
in
like
something
else
like
assembly
script,
to
do
very
small,
bespoke
denials,
because
that's
that's
a
very
nice
use
of
assembly
scripts.
I
mean
that
that's
what
I
think
anyway.
Others
may
may
disagree,
but,
but
I
I
agree
we
should.
We
should
just
create
a
tracking
issue
and
add
these
things
to
it.
C
C
B
B
F
B
Yeah,
I
think
I
think
what
what
we
need
to
present
is
at
least
one
way.
That's
fully
working
and
that's
kind
of
tested
with
everything
right.
So
there
needs
to
be
a
test,
especially
for
something
like
rate
limiting,
because
it
involves
something
from
the
outside
as
well,
and
then
there
is
a
little
bit
more
than
just
enabling
one
thing
and
that's
why
having
a
doc
with
tests
helps.
B
A
Okay,
so
what's
the
decision
when
we
put
really
limiting
under
traffic
management
and
for
other
parts
like
a
header,
control
or
wireless
black
based
denial,
then
we
put
it
under
some
under
extension,.
A
Like
a
new
extension
section
with
webassembly
with
those
filters
treating
web
assembly
right
or
it's
at
the
right
direction,.
B
There
are
only
four
things
on
that
page,
so
one
is
moving
to
trick
management
and
maybe
a
couple
are
moving
to
security,
and
then
we
then
we
should
just
add
a
new
extensions
page
where
there
can
be
overlap
right,
because
we
can
show
that
a
a
deny
list
allow
list
can
be
implemented
in
webassembly
and
then.
G
C
Okay
is
john.
H
Yeah
sorry,
I
joined
now
john
yeah,
so
yeah.
Basically
the
idea
here
is,
I
noticed,
there's
a
couple
cases
where
we
don't
have
any
access
logs
for
failed
requests,
and
it
makes
some
some
debugging
fairly
challenging.
I'm
sure
access
logs
here
could
also
be
replaced
by
metrics.
If
we
want
to,
you
know,
go
a
bit
further,
but
I've
only
looked
at
access
logs.
Personally,
the
two
main
cases
I've
seen
is
when
there's
no
matching
filter
chains,
so
this
is,
as
far
as
I
know,
pretty
much
only
at
the
gateway.
H
H
So
there's
there's
really
just
no
visibility
there.
The
other
one
is
the
listener.
Filter
failure,
specifically
like
protocol
sniffing,
so
that
that's
really
the
main
one
I'm
trying
to
solve
the
other
one
is
would
be
very
useful.
I
think,
but
that's
not
necessarily
my
primary
goal.
H
So
the
the
idea
here
is
that
listener
can
actually
add,
or
they
actually
do
have
a
current
field
for
access
logs
at
the
listener
level,
rather
than
at,
like
the
I
don't
know
where
you
put
in
out
like
the
hcm
or
somewhere
around
there,
and
I
think
we
can
set
it
up
so
that
we
can
filter
for
just
failures,
so
we
don't
get
like
duplicate
logging.
I
did
a
quick
prototype
of
that.
It
seems
to
work.
H
Maybe
we
need
to
do
some
some
more
enhancements
there
to
make
it
more
robust,
but
it
seems
to
kind
of
work.
So
I
guess
there
was
a
couple
questions
here
is
one:
do
we
want
to
do
this
and
if
so,
how
would
the
api
look
for
this?
Like
do?
We
have
the
same
format
and
it's
just
always
on.
If
you
enable
access
logs,
it's
kind
of
transparent
to
the
user
or
you
know,
do
we
have
a
different
format
like
one
of
the
things
with
the
format?
Is
you
know?
H
This
is
at
the
listener
level,
and
the
format
has
a
bunch
of
stuff
that,
like
we
won't
have
access
to.
So
most
of
the
log
is
just
like
dash
dash
dash,
so
I
don't
know
open
door
ideas
there.
I
personally
feel
like
it's
probably
easier
to
just
use
the
same
format,
to
keep
things
simple
and
the
other
one
is
that
the
listener
filter
timeout
will
we
can't
actually
get
any
access
logs,
so
I
have
a
bug
associated
with
that?
That's
that's
it
so
yeah!
That's
that's
pretty
much
it.
What
do
you
guys.
B
Yeah,
the
the
so
the
so
the
second
one
you
mentioned,
there
is
already
a
field
that
that
does
that
at
the
listener
level,
does
it
actually
so
does
it
take
care
of
both
those
cases?
So
it
does.
H
H
Is
we
want
to
remove
the
the
protocol
sniffing
timeout,
and
even
I
guess,
if
we
don't
like
you,
want
to
know
if
you
hit
the
timeout,
get
some
sort
of
log,
I
suppose,
but
you
know,
if
we
remove
the
timeout,
then
we'll
have
some
number
of
cases
where
requests
just
fail
and
they
don't
know
why,
because
they
have
a
server
first
protocol
and
some
scenarios,
so
we
would
love
to
actually
get
an
access
log
there,
rather
than
just
my
request,
is
failing.
I
have
no
idea
what's
going
on.
B
Yeah
and-
and
I
think
that
just
looking
at
that
use
case-
access
log
is
definitely
much
more
appropriate
or
it
won't
be
able
to
take
the
place
rather.
Metrics
won't
be
able
to
take
place
of
it
because
many
times
you
would
want
to
know
the
details
of
like
what
will
like
yeah
more
details
than
just
this
is
the
metric
right.
You
want
to
know
the
now
the
client
ip,
if
that's
relevant
or
where
it
was
trying
to
go,
or
whatever
else
is
available
during
the
filter
chain
match
so
so
yeah.
B
I
I
I
I
agree
that
we
should
start
with
no
configuration
at
all
or,
like
basically
don't
give
any
configurability,
it's
perfectly
reasonable
to
have
the
same
format,
and
the
expectation
is
that
this
lock
should
be.
This
shouldn't
happen
very
often,
if
it
happens
very
often,
then
something
is
wrong.
You
you
have
done
something
wrong.
H
Yeah
I
yeah,
I
would
agree,
I
mean
it
could
happen
from
someone
externally
doing
something
wrong
as
well,
like
you
know,
a
client
sending
a
request
for
an
invalid
server
or
something,
but
I
think
that's
still
useful,
like
you
want
to
know
what
requests
you're
getting
right,
if
someone's
sending
you
thousands
of
invalid
requests,
I'd
rather
get
the
access
logs
for
those
than
just
not
noticed.
F
G
Yeah,
so
I
mean
I
was
just
going
to
say
something
to
get
mandarin
like
start
simple
and
have
the
same
format,
which
of
maybe
the
only
thing
I
would
say,
is
in
our
faqs
or
some
debugging.
We
should
add
that,
when
this
happens,
you
will
see
a
log
which
will
have
many
of
these
fields
not
set
and
what
it
means,
because
we
already
have
access
logs,
sometimes
where
some
of
these
fields
are
not
set
right.
E
I
would
like
to
see
this
too.
I
have
requests
to
get
more
information
about
the
traffic
that
is
flowing
between
two
things,
when
there's
errors
for
troubleshooting.
H
Yeah,
I
think
so
and
then
I'm
writing
it's
down
here.
So
add
the
access
log,
we
use
the
same
format,
flash
api
and
then
in
parallel
we
can
look
at
also
making
the
listener
filter
issues
show
up
there.
H
Yes,
yeah,
that's
I'll!
Add
that
as
well.
F
H
I
mean
like
today
in
mesh
config,
you
have
like
the
access
log
file,
encoding
and
format
like
we
won't
have
a
new
like
listener,
filter
access,
log
format,
we'll
just
use
the
same
stuff,
they've
specified
in
there
and
we'll
transparently
add
the
filter,
for
I
think
it
we
just
add
it
for
like
y
equals
nr,
but
all
to
actually
check
that
is
more
as
robust
as
we
need
it.
H
I
see
I
see
what
you
mean,
that's
a
good
question
I
think
in
in
the
current
state.
It
makes
sense
to
just
stick
it
there.
If
yeah,
if
we
need
to
add
filters
that
will.
B
F
F
F
F
C
H
I
mean
to
me
this
seems
like
something
that
you
most
likely
want
and
we
don't
really
need
a
permanent.
You
know
api
for
it
and
we
can
just
add
a
future
flag
in
case
there's
issues
with
it.
F
B
A
C
H
C
Maybe
we
should
my
agenda.
I'm
gonna
go
straight
to
the
1.8
roadmap.
Since
we
said
we
had
set
aside,
there's
a
there's,
a
link
now
in
the
header,
the
itself
itself.
C
All
right
so.
C
F
I
don't
have
a
full
understanding
how
we're
going
to
combine
any
filter
with
metrics
customization
and
we're
going
to
use
as
a
and
the
photo's
implementation,
or
we're
going
to.
This
seems
to
be
some
conflict
here,
because.
B
B
The
other
option
is
that
these
are
all
compiled
down
to
onboard
filter
and
then
the
the
the
control
plane
proper
only
acts
on
the
onboard
filter,
and
I
I
don't.
I
don't
think
we
have.
G
Yeah
so
the
p0
telemetry
api,
so
that's
a
new
user
facing
api
and
then
the
metrics
customization
api
is
it's
just
the
way
it
is
written.
It
feels
like
they
are
the
same
to
me
unless
you
all
are
implying
something
else
here.
B
B
C
B
G
C
Okay,
this
work:
is
it
mostly
done
the
supportable
envelope
filter
api.
B
B
F
B
Oh
yes,
but
I
think
yes,
something
that
doesn't
crash
on
boy
and
yeah,
something
bad
that
doesn't
happen.
So
actually
we
we
should.
We
should
add
that
to
this
as
well
like
that,
even
though
this
was
just
filter
management,
but
I
I
agree
with
with
your
quad
that
we
we
already
have
some
things
that
we
can
do
to
protect
against
like
instant
metroid
outage,
but
that
has
to
be
one
of
the
one
of
the
things
that
that
we
do
because
it
it.
B
Today,
to
put
in
an
envoy
filter
that
will
either
cause
that
will
either
have
the
effect
of
no
new
proxies
can
come
online
afterwards.
B
F
Yeah
I
mean
the
validation
is
out
of
date.
That's
the
issue
right,
the
validation
that
one
person
one
component,
things
is
not
the
same
as
that
developer,
validation,
and
we
don't
it's
very
hard
to
know
so
unless
you
run
it
so,
but
how
to
do
it
in
call.
This
is
difficult
without
actually
learning
envoy.
B
Is
there
okay?
So
so
we
should
yeah,
let's
the
the
this
this
needs
we
we
need
to.
We
need
to
have
a
dock
or
something
like
that
to
to
to
basically
handle
this
as
well,
and
we
have
seen
mesh
white
crashes
like
I
have
personally
done
them,
and
I
know
kwat
has
two
in
his
own
testing.
So
it's
it's.
B
B
C
It
was
time
to
look
at
the
next
step,
so
I
I
have
concerns
here.
I'm
interested
in
what
the
you
know.
Community
thing
thinking
is
about
just
everything
seems
like
a
p0,
and
I
don't
know
like.
C
Are
we
going
to
work
on
all
of
these
things
as
p0s
or
or
is
there
room
to
sort
of
balance
these
out
like
what
is
the
the
highest
level
task
here?
Is
it
the
the
beta
quality
remote
load,
or
is
it
the
wasm
api.
G
And-
and
then
broadly,
I
would
say
I
mean
if
you
look
at
the
aim
for
the
whole
quarter.
What
are
you
and
mandar
thinking
about
this
working
groups
deliverable
like
creating
a
new
api
and
implementing
itself?
It
has
taken
the
six
plus
months
just
to
get
conferences
user
facing
api
plus,
enabling
the
enabled
ecosystem.
Those
are
two
really
big
features
that
we
are
planning
to
deliver
in.
G
Yeah,
so
I
was
saying
that
we
should
try
to
say
that
we
will
actually
have
a
long-term
api
in
this
release,
which
will
be
alpha
and
then
for
extensions
ecosystem.
Probably
you
might
not.
We
might
not
have.
A
G
E
So
when
I
wanted
to
learn
wasam
and
create
my
own
extensions,
I
decided
to
use
inline
bytes
and
I
thought
it
would
be
a
great
way
to
load
up,
filter
wasm,
really
quickly.
That
feature
still
doesn't
work.
We
can't
send
inline
bytes.
Could
we
fix
those
things
as
well?
So
so,
in
line.
E
So
I
don't
have
a
s
e
c
d
s
server
or
anything
like
that.
No.
E
Okay,
so
I
would
be
willing
to
try
that
what
what
I
had
wanted
to
do
was
to
create
some.
You
know
debug
tools
that
threw
some
filters
on
immediately
and
removed
them,
and
I
wanted
inline
bytes,
because
if
I
used
a
file,
I
had
to
restart
with
that
file
being
mounted.
E
B
Out,
okay,
we
we
will,
we
will
document
that
I
mean
we
can
probably
fix
it.
I
I
don't
know
if
it's
because
of
like
multiple
layers
of
encoding
or
what
I
haven't.
I
haven't
really
looked
at
myself,
but
it's
I.
I
don't
think
that
that
would
be
the
way
that
we
want
our
customers
and
users
to
load
filters
anyway.
So
I
would,
I
would
much
rather
spend
time
on
the
other
means.
E
Everybody
knows
that,
and
so
we,
we
maybe
even
add
some
validation
or
whatever,
to
make
it
illegal
in
sdo
to
use
in
line
bytes.
F
E
I
agree
and
I
did
some
work
in
istio
to
fix
inline
bytes,
so
it
now
is
validated
properly
by
the
web
hook.
So
I
thought
the
problem
was
that
envoy
was
deserializing.
It
incorrectly.
F
B
C
F
What
do
people
think
about
that?
I
mean
the
the
remote
load
is
blocked
by
mboy.
Really
it's
it's
it's
very
hard
to
deliver
it
without
massive
changes
to
anybody.
Like
yes,
I
mean
it's.
Just
a
and
boy
cannot
wait
to
acquire
a
knack,
so
there's
no
basically
escape
route.
If
your
knack-
and
that
requires
android
changes.
B
So
so
so
quad,
I
think
I
I
don't
believe
that
we
need
to
actually
will
address
all
of
that
right,
like
at
least
at
least
the
way
I'm
looking
at
it
is
that
we
now
have
both
the
options
of
knack
on
a
cache,
miss
or
don't
knock
on
a
cache
miss
as
long
as
both
those
options
work
properly,
and
we
have
the
right
metrics
to
track
when
when
there
is
a
knack
or
when
there
are
configures
that
the
thing
that
was
approved
like
last
time,
I
I
would.
B
I
would
consider
that
fine
like,
because
that's
something
that
that
people
can
use-
and
it
will
not
suffer
from
the
immediate
knacks
up
front.
So
so
I
I'm
I'm.
Actually
I
have
sort
of
lower
goals
than
you
do.
I
guess
then,.
F
B
I
think
I
think
we
we
are
going
to
well,
so
we
are
going
to
ask
people
to
monitor
max
or
something
else
right
like
they
have
to
monitor
something,
and
if
we
ask
them
to
monitor
metric
x
instead
of
metric
y
or
metric
x
and
metric
y,
I
I
don't
know
what
like
what?
What
do?
What
do
others
feel
is
that
is
it
unreasonable
to
ask
people
to
monitor.
B
F
Well,
I
think
it's
reasonable
to
expect
to
monitor
things,
but
that
should
be
for
special
cases,
not
for
intermittent
failures.
Intermittent
fast
should
be
recoverable.
F
B
It
will
oh
so,
okay,
so
you,
if
the
well,
there
will
be
there.
There
is
some
retry
there,
but
but
correct.
If,
if
it
is
a
heart
failure
of
the
http
server,
where
you're
hosting
the
bits,
then
the
only
way
to
know
it
would
be
by
monitoring
metrics.
B
B
B
Okay,
so
I'm
yeah,
we
have
a
whole
bunch
of
p0s
here
and
maybe
we
can
downgrade
one
of
those.
C
Yeah,
sorry,
as
I'm
you
talking
to
myself
for
a
while,
I
feel
like
the
the
p0
is
the
delivery
right
getting
getting
the
extension
there
and
then
the
the
next
set
of
things
around
making
sure
it
doesn't
crash
and
you
can
monitor
it
and
everything
else
is-
is
a
lower
priority
right.
Okay,
I
I
think
I
think
I
think.
C
Okay,
are
there
other
things
about?
I
mean
the
extension
readiness
that
we
need
to
think
about
in
this
release.
I
mean
I
know
ed
you
you
looked
at
this
and
we
talked
about
some
of
the
inline
bytes
issues,
but
are
there
other
other
bits,
other
working
groups
working
on
things
like
sdks
and
other
stuff?
I
don't
see
any
of
that
work
here.
Do
we
need
to
call
out
any
of
that
work.
B
Oh
so
I
mean,
since
no
one
here
is
working
on
it.
I
I
don't
know,
though,
what
I
mean
what
I
would
like
to
have-
and
I
think
ed
is
already
doing-
that-
is
to
make
sure
that
our
assembly
script,
whatever
to
link
solo,
is
creating
right.
B
Assembly
script
works
properly,
with
the
released
or
to
be
released
version
of
istio,
and
I
would
also
like
to
see
on
the
page
that
we
are
going
to
create
for
extensions,
simple
assembly
script,
extensions
that
that
do
like
specific
things
that
were
documented
earlier.
E
H
Yeah
one
comment:
there
kubernetes
just
added
warnings
on
the
validation
web
hook,
so
we
have
a
great
way
to
expose
those.
I
mean
we
can
do
an
easter
cuddle
analyze
as
well,
but
it's
even
better.
You
know
right
when
you
apply
it,
you
get
a
warning.
B
But
but
the
issue
there
is
that
api
server
simply
doesn't
know
the
inner
proto
right.
E
H
C
And
is
this
something
that
could
be
shared
with
the
user
experience
working
group?
This
is.
D
E
F
F
E
It
is
a
lot
large
list
I
mean
I
cannot
remember
it's
probably
hundreds.
We
don't
need
to
document
everything.
I'm
mostly
concerned
about
things
that
worked
in
one
five
or
one
six
or
one
seven
that
aren't
going
to
work
in
one
eight,
because
people
will
just
modify
their
one
and
they
will
wonder
why
it
broke.
I
want
to
give
them
a
warning
just
for
those
things
that
are
in
our
samples.
F
F
E
Mean
it's
not
our
fault,
but
several
times
I've
filed
something
and
someone
says
well
yeah,
but
that's
not
the
way
it
is
anymore.
It's
changed.
There
should
be
a
way
for
a
robot
to
tell
me
that
my
filter
has
different
fields
than
a
modern
one
would
have.
G
B
Why
we
are
trying
to
we
are
trying
to
make
it
more
supportable
right,
so
the
there
are.
There
are
parts
that
are
going
to
going
to
remain
break
glass,
but
even
even
for
those.
So,
for
example,
when
the
schema
changes,
if
our
tool
has
the
old
version
of
proto
and
the
new
version
of
proto
and
and
and
it
can
then
say-
okay,
this
this
field
was
dropped
after
the
deprecation
time
or
or
whatever
right.
B
It's
it's.
It's
most
definitely
possible
to
still
warn
people
that
hey
you,
the
the
thing
that
you're
trying
to
upgrade
is
like
may
fail
now,
or
it's
already
failing
right.
You,
like
you're
setting
some
time
out
which
is
not
set
in
some
other
place,
and
this
thing
that
you
have
placed
here
has
no
no
effect.
E
G
D
G
Question
was
also,
I
totally
agree
with
that
with
both
of
your
statements.
My
question
more
geared
towards
is
supportable,
meaning
eventually
graduate
that
api,
or
we
are
not
going
to
graduate
that
api,
but
create
tooling
around
it
to
make
it
more
usable,
like
that's
what
I'm
trying
to
get
at.
If
the
api
version
matters
here
right
in
production,
many
people
won't
use
it
because
of
the
wavy
document,
they're
saying
it's
alpha
and
break
glass,
so
is
it
ever
going
to
be
beta
because
of
these
efforts.
B
Yeah,
I
I
so
I
I
have
I
have
heard
I
I
don't.
I
don't
think
I
don't
think
there
is
consensus.
What
I've
I
would
at
least
like
to
see
part
of
it
beta
and
then
part
of
it
not,
but
but
that
there
isn't
isn't
a
consensus.
Definitely
definitely
not
so,
but
okay,
making
it
more.
Supportable
definitely
helps
in
that
discussion.
C
So
we
have
one
minute:
two
minutes
left:
are
there
other
things
that
have
jumped
out
to
people
about
either
missing
or
incorrectly
being
prioritized
on
the
list
here
before
we
take
another
pass
at
harmonizing?
This,
I
think,
do
we
feel
like
enhancing
cell
debugability
is
really
a
p0
and
we'll
get
that
attention.
B
Yeah
that
that
that
should
be
made
into
a
p1
kind
of
to
correspond
with
the
yeah,
the
top
line
yeah
in
my
mind,
metrics
expiry
and
metadata
support
for
peers
not
in
mesh,
continue
to
be
p0s.
So
that's
more
a
statement
of
need
and
then
commitment
and
we
can
decide
if
we're
still
committed
to
it.
B
Even
this
release,
or
not,
I
mean
based
on
just
the
amount
of
work.
We
feel
that
for
both
of.
C
B
H
A
B
Right
so.
B
B
G
B
B
D
D
So
I
mean
as
long
as
it
doesn't
break,
I
mean
we
had
a
problem
with
the
docks
and
it
would
be
nice
if
it
wasn't
experimental,
maybe
because
I
think
it's
already
working
but.
B
So
so
I
think
so
so
I
think
okay,
how
about
that?
We
can
add
that
to
here
right
we
can
say
that
the
product
request
application
yeah.
We
can
add
the
promotion
here
which
doesn't
include
implementing
all
the
other
features
but
yeah
just
promoting
the
feature.
That's
already
there.
B
G
B
So
I
mean
we,
we
will,
I
think,
do
we
support
full,
lock
customization
in
stackdriver
access
lock.
Today
we
don't
write.
A
C
C
Look
so
we're
over
time,
so
we
should
probably
stop,
but
I
I
will
take
it
past.
It
sort
of
reorganize
this
based
on
what
I
heard
here
and
I
guess
tune
into
the
toc.
Did
we
present
last
week
or
no.