►
From YouTube: Kuma Community Call - September 29, 2021
Description
Kuma hosts official monthly community calls where users and contributors can discuss about any topic and demonstrate use-cases. Interested? You can register for the next Community Call: https://bit.ly/3A46EdD
B
A
Also
feel
free
to
submit
any
topic
for
the
agenda,
we'll
try
to
cover
all
of
it.
I
already
see
topics
from
from
austin-
I
guess
so
yeah
we
will
get
back
to
this,
but
first
I
would
like
to
give
some
update
on
policy
matching.
We
discussed
this
last
community
call,
but
last
minute
call.
I
mostly
outlined
what
problem
we
have
with
the
marching.
Today.
A
I
had
some
ideas.
I
briefly
showed
them,
but
today
is
kind
of
it's
kind
of
final
from
developer
site.
So
now
it's
a
matter
of
review
and
feedback.
If
people
like
it
or
not,
so
I
think
I
will
take
maybe
seven
ten
minutes
to
speak
about
this.
Okay,
so
post
matching
version
two
in
the
previous
document.
A
Here
from
the
previous
call,
you
can
see
the
problems,
the
list
of
problems
if
you're
interested,
but
this
document
contains
concrete
steps
that
we
can
take
to
improve
overall
user
experience
and
the
first
step,
it's
kind
of
not
obvious
that
it
solves
some
problems,
but
we
are
going
to
get
rid
of
inbound
policies
and
we
will
make
all
inbound
policies.
We
will
convert
them
to
data
plan
policies.
A
So
today
there
are
two
types
of
policies,
as
you
can
see:
data
plane,
policy
and
connection
policy
data,
plane
policy,
selects
one
data,
plane
or
group
of
data
planes,
connection
policy,
selects
connection
with
the
source
and
destination
and
before
that
connection
policies,
they
there
were
two
types:
one
of
them
were
applied
on
the
source.
Some
of
them
were
applied
on
the
destination
and
we
decided
to
unify
the
user
experience.
A
We
can
get
rid
of
policies
that
were
applied
on
the
destination
and
make
them
data
plan
policies.
So
the
final
list
of
policies
you
can
see
here,
which
of
them
will
be
data
plane,
which
of
them
will
be
connection
policy,
and
this
is
the
first
change.
Then
we
want
to
add
more
constraints
to
the
source
and
destination.
A
So
today
they
are
kind
of
allows
arbitrary
values.
You
can
put
any
key
any
value,
and
that
gives
a
lot
of
a
lot
of
different
cases
which
is
hard
to
cover,
and
it's
hard
to
say
it's
hard
to
say
about
the
order
of
these
policies,
how
they
will
be
applied,
which
one
is
more
specific
than
another,
and
in
order
to
simplify
that,
we
want
to
replace
key
values
with
the
service
and
service
name
and
tags
tags.
They
select
sub
service,
the
set
of
proxy
inside
service
and
also
we
adding
constraints.
A
A
Later.
We'll
have
we'll
take
a
look
at
the
example
for
timeouts
and
the
lowest
level
and
at
the
same
time
they
have
highest
priorities,
so
they
mo
the
most
specific
layers.
They
are
for
service
owners,
so
service
owner
have
the
last
word
on
what
settings
should
be
applied
for
outbound
of
of
the
service,
and
here
we
can
briefly
take
a
look
at
the
example,
for
example,
as
a
mesh
operator,
I
define
timeout
policy
in
in
this
way,
so
I
say
any
service
to
any
service.
A
I
want
connection
time
out
to
be
10
seconds,
request
about
five
seconds
idle
time
out
for
grpc
one
hour,
yes
and
then,
for
example,
as
a
service
owner
of
the
back
end.
I
have
more
knowledge
about
sla
of
my
service
and
all
that
stuff,
and
I
can
define
such
type
of
policy
to
say
to
to
be.
This
policy
will
be
applied
on
the
clients
of
my
service
and
this
time
out
will
be
applied
on
the
clients.
A
So,
for
example,
I
know
that
in
average
my
method
works
about
20
seconds
more
more
than
at
least
10
seconds.
I
don't
know
anyway,
I
can
overwrite
the
admin,
the
mesh
operators
parameters
with
my
parameters
with
my
parameters,
and
here
we
go
deeper
and
if
I'm
service
owner
of
the
web,
I
can
overwrite
timeouts
on
of
my
proxies
proxies
that
implements
web.
A
So
I
can
override
it
third
time,
so
it
will
be,
for
example,
10
seconds
and
another
level,
which
is
even
lower
more
specific.
I
can
put
some
special
values
from
web
to
back-end.
Specifically,
if
I'm
web
service
owner,
I
can
or
put
some
special
values
for
back-end
how
it
will
work
today.
We
just
take
the
most
specific
policy
and
we
apply
it,
but
it
has
some
problems.
That's
why
we
want
to
take
all
matched
policies
from
all
levels
from
this
table
and
merge
them
together,
and
here
we
have
step
three
which
is
about
merging.
A
A
Next
step
is
also
pretty
important,
excluding
because
you
may
have
policy
for
everything,
except
maybe
one
service
or
except
one
connection
between
services,
and
now
it
will
be
much
easier
to
define.
We
have
the
semantic
is
the
same,
but
we
have
at
least
two
options.
How
we
can
express
this
in
yaml
first
option:
when
you
create
selector,
you
can
define
service
any
and
not
service
backend.
So
we
can
introduce
not
service
and
not
text.
A
Our
name
could
be
different
and
another
option
is
to
have
another
selector
in
the
root
which
named
exclude
selector,
for
example,
that
do
absolutely
the
same.
But
without
not
and
it's
kind
of
the
same
semantic,
it
will
work
the
same
way,
but
we
didn't
decide
on
what
option
is
better
and
the
same
exclude
stuff
will
work
for
connection
policies
as
well,
where
we
also
not
sure
about
if
it
should
be
exclude
sources
or
not
service
for
sources
and
not
service
for
destination.
A
A
A
We
know
that
it's
important
from
the
envoy
perspective
the
order
of
the
roads,
how
they
will
be
matched
and
we
need
one
source
of
truth
for
routes,
and
this
should
be
traffic
road
policy,
so
in
traffic
routine
already
they
can
define
roles,
but
they
are
not
named,
but
we
want
to
give
opportunity
to
put
a
name
for
every
route
and
then
you
can
reference
this
name
from
another
policies
like,
for
example,
timeout
will
look
like
this.
You
define
timeout
policy
and
you
put
road
name
any.
This
is
probably
predefined
road.
A
You
will
always
have
to
define
road,
just
slash
yeah
and
you
can
create
your
own
roads
and
target
them
in
the
policies,
and
there
are
some
notes
about
overriding
here.
We
have
a
list
of
all
policy
changes
that
will
happen
at
the
end.
We
still
don't
have
don't
have
a
plan,
how
to
roll
out
the
things,
but
we
will
work
it
out
later.
A
A
C
A
Oh,
if
they
do
this
for
the
same
destination,
then
I
think
it
will
be
just
merged
into
one
chain
of
routes.
It
will
go
down
to
envoy
and
then
it
depends
on
the
order.
We
predict,
we
declare
which
order
will
be.
I
think
it's
there
is
no
somewhere
here,
how
we
merge
lists,
but
anyway,
from
the
base
policies,
items
of
the
list
will
go
to
the
bottom,
so
they
will
be
less
specific.
So,
okay,.
C
A
C
Trying
to
trying
to
ensure
that
we'd
accounted
for
the
possibility
of
team
a
defining
a
traffic
route
object
for
you
know,
slash
offers
and
then
team
b
being
unaware
that
team
a
had
done
that
which
I
know
sounds
silly,
but
big
companies
do
things
like
this
also
goes
in
and
defines
a
traffic
route
object
of
slash
offers,
but
points
different
service
right,
because
there
was
a
lack
of
coordination
and
then
and
then
we
have.
The
information
should
slash
offers,
go
to
service
a
or
should
slash
offers,
go
to
service
b.
D
D
You
can
use
in
other
policies
without
kind
of
defining
this
in
every
traffic
route
of
every
service
right,
but
still
if
there
is
a
route
main
main
offers
in
the
default
routes
and
you
as
a
service
owner,
you
want
to
define
offers
like
red,
red,
define
or
override.
However,
you
want
to
call
this
merging
of
lists
like
elias
said,
will
be
kind
of
reversed
right,
so
whatever
you
put
as
a
service
owner,
which
is
kind
of
player
with
a
higher
priority,
will
be
put
on
top
right.
D
C
C
D
Well,
it
shouldn't,
assuming
that
there
is
some
mechanism
like
our
back
right.
You
could
like,
if
you
have
some
mechanism,
that
restrict
owners
of
service
back-end
to
only
apply
proper
resources
right.
There
should
not
be
a
situation
that
other
team
is
applying
resource
is
applying
policies
for
your
service
right,
but
also
keep
in
mind
that
routes
are
created
like
from
unvoiced
android
perspective
right.
They
are
created
on
the
client
side.
C
D
Sure
yeah
it
is,
it
is
a
complicated
problem
right
overall.
How
to
do
this
policy?
Matching,
I
think
illya
is
design,
is
redesigning
this
for
like
what
the
second
week
first
week
so
like
we,
we
went
through
many
many
iterations
on
this,
and
we
finally
have
something
that
we
are
kind
of
happy
about.
So,
but
still,
if
you,
if
you
have
more
ideas
or
better
ideas,
how
to
improve
this,
we
are
very
happy
to
hear
them.
A
E
I
don't
have
anything
prepared,
basically,
the
prometheus
maintainer,
who
helped
us
get
in
the
kumasti
asked
for
the
deprecation
of
the
prometheus
st.
So
I
wanted
to
open
the
discussion
on
if
we
could
start
that
process.
Maybe
an
initial
proposal
is
just
a
log
message
when
that
starts
and
then
figuring
out
a
migration
path.
Does
anyone
see
any
problems
with
starting
that
deprecation?
E
D
E
D
E
A
E
E
D
E
D
B
B
D
Well,
I
think
I
think
some
initial
versions
should
be
available
this
year.
Maybe
like
it's
hard
to
give
estimates,
we
don't
have
any
official
estimates
at
this
moment,
but
james
is
actively
working
on
gateway
and
I
think
that
he
is
building
some
end-to-end
tests
right
now
for
basic
usages
right.
So
it
will
take
some
time
to
figure
out
all
the
all
the
edge
cases
and
to
enrich
this
with
all
the
functionality
like
tls,
but
some
basic
functionality.
It
seems
like
it's.